1 00:00:05,830 --> 00:00:12,070 Hi, this is Laura Chappell and welcome to this video on Deep Space Networking Traffic Analysis. 2 00:00:12,510 --> 00:00:24,090 In this video I'm going to show you how I open up a trace file inside of Wireshark and begin the process of customizing Wireshark for Deep Space Networking Traffic Analysis. 3 00:00:24,130 --> 00:00:30,450 And we'll go through and learn about the Bundle Protocol and we'll learn about the TCP Convergence Layer. 4 00:00:30,450 --> 00:00:33,090 So let's go over to Wireshark and get started. 5 00:00:33,690 --> 00:00:41,250 In Wireshark I've opened up the trace file depicting the Deep Space Networking Traffic. 6 00:00:41,250 --> 00:00:50,650 Now we're talking about Delay and Disruption Tolerant Networking here, or DTN we simply refer to it as. 7 00:00:50,650 --> 00:01:03,650 And in this scenario we have a host that is sending a bundle of data in bundle segments to another host to be relayed to a third host. 8 00:01:03,730 --> 00:01:06,250 So let's see what we have in this trace file. 9 00:01:06,250 --> 00:01:11,870 First of all we have some traffic that doesn't have anything to do with our DTN communications. 10 00:01:11,870 --> 00:01:14,170 It's this OSPF traffic. 11 00:01:14,170 --> 00:01:16,190 So I'm going to get that out of the way. 12 00:01:17,430 --> 00:01:21,690 Now what we're left with are some interesting packets here. 13 00:01:21,690 --> 00:01:27,130 First of all, these top packets that you see, they're UDP packets. 14 00:01:27,130 --> 00:01:29,470 They're kind of sprinkled throughout the trace file. 15 00:01:29,470 --> 00:01:45,570 If you were to select one of those packets and look down in the packet bytes window, what you would see is in the data portion it appears that we have a host that is announcing its DTN endpoint ID. 16 00:01:45,570 --> 00:01:53,010 So 10.0.0.1 is announcing that its endpoint ID is N1. 17 00:01:53,330 --> 00:01:55,210 Kind of like its name. 18 00:01:55,390 --> 00:02:02,610 On the second packet there we have 10.0.0.2 announcing its endpoint ID as N2. 19 00:02:02,610 --> 00:02:09,810 And the next packet 10.0.0.3 announcing its endpoint ID as N3. 20 00:02:09,810 --> 00:02:17,850 Alright, that information right there is very interesting but it's not a data transfer process. 21 00:02:17,850 --> 00:02:19,870 That is just an announcement. 22 00:02:19,870 --> 00:02:25,010 What we're interested in are the TCP CL packets. 23 00:02:25,010 --> 00:02:33,030 So frame number 7 there is the first time we see a TCP Convergence Layer packet. 24 00:02:33,030 --> 00:02:35,570 And this is just a keepalive. 25 00:02:35,570 --> 00:02:43,450 By looking at these keepalives we can get a general idea of which hosts can see which hosts. 26 00:02:43,450 --> 00:02:50,390 So in frame number 7 we have 10.0.0.3 sending a keepalive to .4. 27 00:02:50,390 --> 00:02:54,010 In the next packet we have .1 sending a keepalive to 3. 28 00:02:54,410 --> 00:02:57,590 In packet 9 we have 3 sending a keepalive to 1. 29 00:02:57,690 --> 00:03:05,390 And then a little bit further on we see in packet 19 we have .2 sending a keepalive to 4. 30 00:03:05,390 --> 00:03:07,810 Alright, we can build a picture from this. 31 00:03:08,030 --> 00:03:10,190 This is what we know so far. 32 00:03:10,190 --> 00:03:14,490 It appears that we have 4 hosts. 33 00:03:15,770 --> 00:03:22,010 And based on the keepalives we can see which hosts are talking to which hosts. 34 00:03:22,010 --> 00:03:31,210 So we can see based on the keepalive that .1 can see .02, .2 can see 4, 4 can see 3, 3 can see 1. 35 00:03:31,210 --> 00:03:34,530 But we don't see any keepalives going between .1 and .4. 36 00:03:34,530 --> 00:03:37,770 We don't see any keepalives between .2 and .3. 37 00:03:37,770 --> 00:03:41,090 So perhaps we have something in the way between those two hosts. 38 00:03:41,090 --> 00:03:43,290 It could be something like a planet. 39 00:03:43,530 --> 00:03:49,670 So here I have a picture, one of the various pictures of Venus with a color filter on it. 40 00:03:49,710 --> 00:03:51,830 Now let's go back to the trace file. 41 00:03:53,170 --> 00:03:57,830 So let's take a look at when data actually begins to be sent here. 42 00:03:57,830 --> 00:04:07,390 We see an awful lot of those endpoint ID announcements and we see a bunch of keepalives and we see some acknowledgments for those keepalives. 43 00:04:08,950 --> 00:04:19,350 When we get down to frame number 57, that's the first time we see a larger length frame that probably has some data in it. 44 00:04:19,350 --> 00:04:29,510 So let's create a profile in Wireshark and we'll begin the customization process to help us analyze deep space networking traffic. 45 00:04:30,030 --> 00:04:35,970 So in the bottom right hand corner on the status bar in Wireshark, it says Profile Default. 46 00:04:35,970 --> 00:04:50,230 I'm going to right mouse click on that column there on the bottom and say New and I'm going to name this profile DTN Example and I'll say OK. 47 00:04:51,170 --> 00:04:57,470 Now Wireshark takes me back to the default settings for profiles and this font is way too small. 48 00:04:57,470 --> 00:04:59,370 There's no way I'll be able to see that. 49 00:04:59,370 --> 00:05:07,330 So I'm going to zoom in here using the enlarge button on the main toolbar until I get to a font size that I like. 50 00:05:08,110 --> 00:05:12,330 Now with all of my profiles, I always add one special column. 51 00:05:12,330 --> 00:05:17,190 I like to have it up with all the work that I do analyzing traffic. 52 00:05:17,490 --> 00:05:23,510 And that column is one that will tell me the conversation numbers in the trace file. 53 00:05:23,510 --> 00:05:28,510 Wireshark numbers all the UDP conversations and it numbers all the TCP conversations. 54 00:05:29,130 --> 00:05:34,150 It starts numbering each of them at zero and they are exclusive of each other. 55 00:05:35,030 --> 00:05:43,310 I'm going to go into the very first packet in here and inside the UDP header, there is a field called the Stream Index field. 56 00:05:43,410 --> 00:05:47,250 And I want to add this as a column. 57 00:05:47,250 --> 00:05:52,870 To add a field as a column, you simply right mouse click on that field and say Apply as column. 58 00:05:53,270 --> 00:06:00,530 I'm going to right mouse click on that column heading and choose to align center for the contents of that column. 59 00:06:00,850 --> 00:06:05,590 Now we've started creating this great column, but we're not quite finished yet. 60 00:06:05,590 --> 00:06:09,730 Because our TCP traffic is not showing up with a stream index number. 61 00:06:09,730 --> 00:06:14,550 We've only told Wireshark to add a stream index column for UDP. 62 00:06:14,550 --> 00:06:20,590 So I'm going to right mouse click on that column header, and I'm going to choose to edit the column. 63 00:06:21,290 --> 00:06:32,010 And I can see right here that the field that it's based on is udp.stream and I'm going to add on to this to say or tcp.stream. 64 00:06:32,190 --> 00:06:39,670 Doesn't matter if you do tcp.stream or udp.stream or this direction, doesn't matter, either way that will work. 65 00:06:39,670 --> 00:06:41,190 And I'm going to say OK. 66 00:06:41,770 --> 00:06:42,890 There we go. 67 00:06:43,130 --> 00:06:53,250 Now, as conversations are intertwined, it's easier for me to see which conversation I'm currently working in because I have the conversation number on the left hand side. 68 00:06:56,850 --> 00:07:03,490 So the next thing I want to do is I want to pull out the most active conversations in this trace file. 69 00:07:03,490 --> 00:07:11,730 I'm going to go up to statistics and conversations, and I'm interested in the most active conversations based on the TCP layer. 70 00:07:12,190 --> 00:07:22,410 I'm going to sort based on the byte count from high to low, and there I can see I have two conversations of interest here. 71 00:07:22,410 --> 00:07:24,570 These top two are what I want to look at. 72 00:07:24,570 --> 00:07:26,590 That's data flowing. 73 00:07:27,530 --> 00:07:34,470 So I'm going to right mouse click on the very first line here, which is traffic between .3 and .1. 74 00:07:34,850 --> 00:07:40,770 I'm going to right mouse click and prepare a filter based on the selected value going in both ways. 75 00:07:41,990 --> 00:07:46,730 And then I'm going to go to the second line, and I'm going to right mouse click, prepare a filter. 76 00:07:46,730 --> 00:07:52,470 And this time I'm going to say or selected, going in both directions. 77 00:07:53,390 --> 00:08:03,890 Wireshark builds the filter for me in the background, and I can see exactly what this filter is based on, the IP addresses that it's based on. 78 00:08:04,450 --> 00:08:07,290 And I'll go ahead and I'll just apply that filter now. 79 00:08:07,610 --> 00:08:13,030 So I have two conversations, the top two conversations showing in this trace file. 80 00:08:13,890 --> 00:08:21,050 I'm going to go to file, and I'm going to save this as a separate trace file now. 81 00:08:21,050 --> 00:08:23,170 Just these two conversations. 82 00:08:23,750 --> 00:08:31,890 I'll go to file, export specified packets, and I'm going to call this DTN example. 83 00:08:34,710 --> 00:08:42,570 Now I'm going to open up that trace file called DTN example, because by default, Wireshark only saves the filtered packets. 84 00:08:42,570 --> 00:08:44,670 So here we go. 85 00:08:44,970 --> 00:08:47,510 Now we have some Keep Alive segments. 86 00:08:48,550 --> 00:08:51,950 Let's take a look down in the packet details window. 87 00:08:52,710 --> 00:09:05,030 Here we can see we have an Ethernet header, an IP header, a TCP header, and then after the TCP header, we have the DTN, TCP Convergence Layer Protocol, or TCPCL. 88 00:09:05,030 --> 00:09:13,410 It has its own header, and for Keep Alives, all we have is this single little field here saying that it is a Keep Alive. 89 00:09:13,410 --> 00:09:24,690 I want my Keep Alives to kind of melt into the background here, so I'm going to set up a coloring rule to change the way these show up in the packet list pane, so they kind of melt away. 90 00:09:24,690 --> 00:09:27,690 I also don't need my capture filter anymore. 91 00:09:28,170 --> 00:09:39,010 So in the detail window, I'm going to right mouse click on this Keep Alive packet, and I'm going to colorize this with a filter and create a new coloring rule. 92 00:09:39,990 --> 00:09:48,310 There's the syntax put in there for this coloring rule, and I'm just going to call it TCPCL Keep Alive. 93 00:09:49,790 --> 00:10:02,230 On the bottom of this coloring rules window, I'm going to click the background button, and I'm going to change the background color to sort of a washed out grayish color, let's say. 94 00:10:03,270 --> 00:10:05,910 I'll click OK and OK. 95 00:10:07,630 --> 00:10:13,770 Now, those Keep Alives have their own background color of this gray showing up. 96 00:10:15,610 --> 00:10:27,710 The next thing I want to do is I want to look for anywhere where it says Bundle Protocol, and I should expand the protocol column so you can see what's marked as TCPCL. 97 00:10:28,390 --> 00:10:39,810 Frame number 14 shows up, and in the info column it says Bundle TCPCL Segment, TCP Segment of a Reassembled Protocol Data Unit. 98 00:10:39,810 --> 00:10:47,130 Wireshark's TCP Reassembly function is on, and we'll talk about how that affects the view in just a little bit. 99 00:10:47,370 --> 00:11:10,150 But if we look inside of frame 14, I'm going to move this up, what we can see is we can see that we have the TCP header, and then right after that, Wireshark is telling us that three different segments have been reassembled to create this bundle segment. 100 00:11:10,810 --> 00:11:19,070 Let's stop for a moment and let me show you how bundles relate to bundle segments, which relates to TCP segments. 101 00:11:19,970 --> 00:11:29,190 So the Bundle Protocol is essentially an application, and you would have some other application that uses it. 102 00:11:29,190 --> 00:11:33,990 So let's say you wanted to do FTP across the galaxy. 103 00:11:33,990 --> 00:11:34,950 You could do that. 104 00:11:34,950 --> 00:11:41,490 You would type in your FTP commands, but that command would go through the Bundle Protocol to transfer data. 105 00:11:41,510 --> 00:11:46,050 So we would have a bundle here of data, and bundles need to be transferred around. 106 00:11:46,050 --> 00:11:56,610 It could be scientific information, it could be video, it could be pictures of the surface of a planet or something like that, it doesn't matter. 107 00:11:56,610 --> 00:12:02,870 You have this big bundle of data, and the Bundle Protocol is a store-and-forward protocol. 108 00:12:02,870 --> 00:12:08,490 Again, it's covered in RFC 5050 if you want to go look up some information about this. 109 00:12:08,750 --> 00:12:18,010 But when a bundle of data is going to a target system, it can be split up into bundle segments, and that is what we see in this trace file. 110 00:12:18,090 --> 00:12:26,890 In this trace file, the bundle that is being transferred from the first host to the relay has split the bundle up into four different segments. 111 00:12:27,010 --> 00:12:41,330 When we look at it on the cabling system, it's really strange because we're so used to an application sending down a certain amount of data, and then the TCP segments go all the way to the end of the data and stop. 112 00:12:41,390 --> 00:12:44,530 That's not the way it's done with the Bundle Protocol. 113 00:12:44,530 --> 00:12:54,910 A TCP segment may have some data from Bundle Segment A, and it may have some data from Bundle Segment B inside of it. 114 00:12:56,250 --> 00:13:09,790 So you can see that if this first bundle segment is going across the network, it's got a TCP segment, another TCP segment, and then part of the third TCP segment is part of Segment A. 115 00:13:09,790 --> 00:13:18,590 And then Bundle Segment B goes out, but part of Bundle Segment B is sitting in the third TCP segment here. 116 00:13:18,630 --> 00:13:29,570 And then we have a TCP segment devoted to Bundle Segment B, another one, and then we only needed part of another TCP segment, but why stop the TCP segment and create a new one? 117 00:13:29,570 --> 00:13:30,110 Nope. 118 00:13:30,110 --> 00:13:36,110 We will have Bundle Segment C, and it starts in the middle of a TCP segment. 119 00:13:36,110 --> 00:13:44,050 Literally, you will see a header inside of this segment right here, indicating that this new bundle is coming up. 120 00:13:44,710 --> 00:13:47,530 Same thing with the final bundle segment. 121 00:13:47,970 --> 00:13:54,930 There will be a header right at the beginning of this bundle segment saying that this is the start of a new set. 122 00:13:56,750 --> 00:14:05,210 So, let's go take a look at these bundle segments as they show up delivered by TCP segments. 123 00:14:06,850 --> 00:14:22,830 So in the Info column, we see on frame number 14, it says Bundle TCP CL Segment, and when we click on it, we have an indication here of which packets were required to put together this first bundle segment. 124 00:14:22,830 --> 00:14:26,310 Frame number 11, frame 13, and frame 14. 125 00:14:26,310 --> 00:14:32,330 And the numbers in parentheses are how much data fits into this bundle segment. 126 00:14:34,350 --> 00:14:36,170 Now we can also see below this. 127 00:14:36,170 --> 00:14:44,590 This is the TCP Convergence Header, and unlike the TCP CL Keep Alive, there are more fields. 128 00:14:44,590 --> 00:14:49,090 There are a total of four fields in this TCP Convergence Header. 129 00:14:49,090 --> 00:14:54,790 So we have the packet type field, so this is data. 130 00:14:55,030 --> 00:14:58,410 Then we have, this is indented, so don't get stuck on this. 131 00:14:58,410 --> 00:14:59,930 These are not new fields. 132 00:15:00,050 --> 00:15:03,250 This is the summary line for these two below. 133 00:15:03,250 --> 00:15:13,930 There is one bit that would indicate if this is the start of the entire bundle, and there's another bit that indicates if this would be the last packet of the entire bundle. 134 00:15:13,930 --> 00:15:22,470 And then we have a line that tells us how large that TCP bundle segment is. 135 00:15:22,470 --> 00:15:25,910 That is a bundle segment length. 136 00:15:29,100 --> 00:15:36,040 So let's do some customization of Wireshark based on these fields. 137 00:15:36,340 --> 00:15:43,020 Number one, I want to take the packet type field, and I'm going to right mouse click on this and apply this as a column. 138 00:15:43,260 --> 00:15:43,980 There we go. 139 00:15:43,980 --> 00:15:48,780 It's easy now to see the difference between Keep Alives There and where data packets are. 140 00:15:48,780 --> 00:15:53,880 And then I also want to do the same thing for Segment Contains Start of Bundle. 141 00:15:53,920 --> 00:16:03,420 I'm going to right mouse click here, and this is the Start of Bundle packet, so I'm going to apply this as a column, and we can see that it's true. 142 00:16:03,640 --> 00:16:05,740 I'm going to center align that. 143 00:16:07,100 --> 00:16:16,700 And then this next field, Segment Contains End of Bundle, I'm going to add that as a column, and I'll center align that. 144 00:16:17,060 --> 00:16:31,420 Now it's pretty easy to look through the trace file and see which packets are the start of the bundle, and then farther on we'll be able to see which packets are the end of the bundle. 145 00:16:31,420 --> 00:16:38,880 That's the end of the entire bundle, not the bundle segment, but the bundle itself. 146 00:16:38,880 --> 00:16:44,620 To make it even easier to detect these, I'm going to set up two coloring rules. 147 00:16:44,640 --> 00:16:54,520 I'm going to set up one coloring rule that turns all packets that are the start of the bundle a green color and then the end of the bundle red. 148 00:16:54,820 --> 00:17:16,520 So in frame number 14 I'm going to right mouse click on this line that says Segment Contains Start of Bundle, and I'm going to choose Colorize with Filter, New Coloring Rule, and it's already set to a 1 because this is the start, so I'm going to just name this Start of Bundle, 149 00:17:16,520 --> 00:17:24,380 and then for the background I'm going to choose sort of a lime green-ish. 150 00:17:27,720 --> 00:17:36,280 Now by setting that coloring up, it's very easy for me to detect where the start of the bundles are in the trace file. 151 00:17:36,280 --> 00:17:38,680 Three of the packets should have matched that. 152 00:17:38,780 --> 00:17:40,320 Here's another thing we can do. 153 00:17:40,320 --> 00:17:47,980 We can right mouse click on that field and just simply prepare a filter based on the selected value. 154 00:17:47,980 --> 00:17:56,300 That just puts that filter to detect the start of bundle packets up in my display filter area. 155 00:17:56,500 --> 00:18:00,920 And on the far right hand side of the display filter area there's a little plus there. 156 00:18:01,240 --> 00:18:05,180 I'm going to click that plus and I'm going to turn this into a button. 157 00:18:05,280 --> 00:18:09,640 I'm going to give the button a label which is going to be S-Bundle. 158 00:18:09,640 --> 00:18:12,500 That to me means Start of Bundle. 159 00:18:12,900 --> 00:18:14,400 I'll say OK. 160 00:18:14,980 --> 00:18:16,020 Now I have a button. 161 00:18:16,020 --> 00:18:23,360 When I click on it, any packets that have the Start of Bundle bit set to a 1 will show up. 162 00:18:24,000 --> 00:18:27,300 Let me clear out the filter that the button just applied. 163 00:18:27,920 --> 00:18:32,280 I want to do the same thing with the End of Bundle. 164 00:18:32,280 --> 00:18:33,880 I want to give it a color. 165 00:18:33,880 --> 00:18:40,780 I'm going to give it a vibrant red and then I'll make a button so I can easily detect the End of Bundle and just show those packets. 166 00:18:40,860 --> 00:18:44,680 Now this packet has the End of Bundle bit set to a 0. 167 00:18:44,680 --> 00:18:48,580 I'm going to change that to a 1 when I do my coloring rule. 168 00:18:48,580 --> 00:18:52,740 I'm going to change that to a 1 when I do my display filter button. 169 00:18:53,120 --> 00:19:04,460 So I'm going to right mouse click on this packet, colorize with a filter, new coloring rule, name it End of Bundle. 170 00:19:05,420 --> 00:19:09,600 And I'm going to give it a background color of this vibrant red. 171 00:19:09,880 --> 00:19:12,420 I'll say OK, OK. 172 00:19:12,640 --> 00:19:15,320 So now it's very easy. 173 00:19:16,740 --> 00:19:19,020 Oh, I forgot to change the number. 174 00:19:19,500 --> 00:19:22,920 Well, it's good for you to see how to edit coloring rules. 175 00:19:22,940 --> 00:19:27,040 To edit a coloring rule, we go to View, Coloring Rules. 176 00:19:27,280 --> 00:19:30,760 And I wanted to change this to a 1 at the end. 177 00:19:31,400 --> 00:19:32,900 There we go. 178 00:19:34,760 --> 00:19:41,200 Alright, so now we can see there's the start of a bundle, there's the end of a bundle. 179 00:19:41,360 --> 00:19:47,120 There's a start of a bundle, and there's the end of a bundle right here. 180 00:19:47,600 --> 00:19:55,180 The first start of bundle we see going from 10.0.0.1 to 10.0.0.3. 181 00:19:55,180 --> 00:20:05,140 So the first thing we see in here is we see a bundle being transferred from .1 to .3 in Bundle Segments. 182 00:20:05,320 --> 00:20:14,380 After that bundle is done, right there, then down on frame 37, we see another bundle starting. 183 00:20:14,380 --> 00:20:17,460 And this bundle is from .3 to .4. 184 00:20:17,460 --> 00:20:21,560 This is the first bundle being forwarded on by .3. 185 00:20:21,560 --> 00:20:23,780 So it's being relayed on. 186 00:20:25,020 --> 00:20:32,840 And then we see the end of that bundle after it's been relayed. 187 00:20:33,500 --> 00:20:40,580 And the very last packet that we see here, from .3 going back to .1, it's a little strange. 188 00:20:40,580 --> 00:20:42,440 It's its own bundle. 189 00:20:42,440 --> 00:20:48,520 We can see that the start of bundle is set at true, and the end of bundle is set at true. 190 00:20:48,520 --> 00:20:53,020 First of all, I want to pop up a button up here for end of bundle. 191 00:20:53,380 --> 00:20:58,480 Well I'll use this packet since it has the end of bundle bit set on. 192 00:20:58,900 --> 00:21:08,600 I'm going to go inside the TCP Convergence Layer here, right mouse click, I'm just going to prepare it as a filter based on the selected value. 193 00:21:08,960 --> 00:21:09,660 There it is. 194 00:21:09,660 --> 00:21:11,440 That's what I want to build the button on. 195 00:21:11,540 --> 00:21:16,240 So I'm going to click plus and give it a name, eBundle. 196 00:21:16,240 --> 00:21:18,420 That means end of bundle to me. 197 00:21:18,620 --> 00:21:23,720 So now if I want to see the end of bundle packets only, I can click on the second button. 198 00:21:23,720 --> 00:21:27,160 I want to see the start, I can click on the first button. 199 00:21:27,340 --> 00:21:29,680 I'm going to go ahead and clear this out. 200 00:21:30,040 --> 00:21:43,240 Now you'll notice that after this bundle has been relayed from 3 to 4, there's this packet, this strange packet here, where it has the start and end of bundle bits set on. 201 00:21:43,240 --> 00:21:45,820 That means it's its own little bundle. 202 00:21:46,140 --> 00:21:50,780 And this is actually a reporting packet. 203 00:21:50,900 --> 00:21:54,020 So let's go inside of it and take a look. 204 00:21:54,420 --> 00:22:03,440 Let me bring up this, let's see, I'm going to bring this sort of up so we see it up on top. 205 00:22:05,360 --> 00:22:08,760 And it is frame 49 we're interested in. 206 00:22:08,760 --> 00:22:17,120 And when we look inside of frame number 49, we see the TCP convergence layer indicating it's the start of a bundle and the end of a bundle also. 207 00:22:17,120 --> 00:22:19,700 So we're obviously not transferring a bunch of data here. 208 00:22:19,900 --> 00:22:23,900 And then we'll see the primary bundle header. 209 00:22:24,880 --> 00:22:30,420 And if we look a little bit further in here, we will see a payload header. 210 00:22:30,620 --> 00:22:34,400 And beyond this we have the administrative record. 211 00:22:34,400 --> 00:22:40,580 So this is indicating right here that this is a bundle status report. 212 00:22:40,580 --> 00:22:42,960 That's the purpose of this packet. 213 00:22:43,480 --> 00:22:49,820 I don't want this packet to be colored red just because it hit the end of bundle coloring. 214 00:22:49,820 --> 00:22:52,660 I want this packet to have its own coloring. 215 00:22:52,660 --> 00:23:14,160 So I'm going to right mouse click on the line that says administrative record type, bundle status report, and I'm going to choose to colorize this with a filter, make a new coloring rule, there's that line, admin record type 1, and I'm just going to say that this is the admin report. 216 00:23:14,620 --> 00:23:25,520 I'm going to turn the background yellow for this one, say OK, and now there we go. 217 00:23:25,520 --> 00:23:28,960 This is the admin report. 218 00:23:28,960 --> 00:23:38,700 And that admin report is being sent from .3 to .1 to say that I successfully delivered the bundle on for you. 219 00:23:39,180 --> 00:23:45,300 So now let's go up and just take a look at some of the packets in here and how this works. 220 00:23:46,090 --> 00:23:52,900 In frame number 14, Wireshark says this is a bundle segment. 221 00:23:53,820 --> 00:24:11,120 And sure enough, if we look inside, we can see the data packets that were required to make up this bundle segment, packet 11, packet 13, and packet 14, and we can see the amount of data in each of those segments to make up, in each of those TCP segments to make up this bundle segment. 222 00:24:11,220 --> 00:24:20,380 And then when we look down at frame number 18, again on the right hand side, it says bundle TCP CL segment. 223 00:24:20,640 --> 00:24:32,000 And if we look inside of that frame, we can see which TCP segments were required to make up this bundle segment. 224 00:24:32,000 --> 00:24:34,540 And there's the weird one right there. 225 00:24:35,100 --> 00:24:47,060 So some of the data that's in packet number 14 is part of bundle segment A, whereas some of the data in packet 14 is part of bundle segment B. 226 00:24:47,060 --> 00:24:48,680 The second bundle segment. 227 00:24:49,170 --> 00:24:50,800 It's very interesting. 228 00:24:50,840 --> 00:24:53,220 It's a bit of a different protocol. 229 00:24:54,120 --> 00:25:06,160 And if we keep looking down here, in frame number 26, frame number 26 is listed here as bundle TCP CL segment. 230 00:25:06,160 --> 00:25:14,160 And if we look inside of there, we can see, oh let's see, 14, I think I did that one before. 231 00:25:14,160 --> 00:25:19,520 Let's clear that out and let's go beyond that to the next bundle segment. 232 00:25:20,040 --> 00:25:21,920 Oh, maybe I didn't, I don't remember. 233 00:25:23,280 --> 00:25:38,020 So I'm clicking on frame number 26, and in frame 26, oh it just hadn't clicked, I didn't click on frame 26 before, it was still selecting frame number 18. 234 00:25:38,280 --> 00:25:47,760 So now I'm on frame number 26 that says some of its data is in frame number 18, some of it is in 23, 24, and 26. 235 00:25:50,660 --> 00:25:58,960 And then the last bundle segment is actually the one that finishes up the whole bundle. 236 00:25:58,960 --> 00:26:14,020 So frame number 32, we can see its data, and if we look down here we can see exactly which frames were required, which TCP segments were required to get this bundle segment across. 237 00:26:14,760 --> 00:26:24,840 It is pretty, it can be pretty confusing to look at this because we have bundle segments and then we have TCP segments, and they don't necessarily align. 238 00:26:25,700 --> 00:26:28,880 Along the way here we had some ACKs showing up. 239 00:26:28,940 --> 00:26:37,300 So here we have the first bundle segment up here, and then we have an ACK down here on frame number 20. 240 00:26:37,300 --> 00:26:46,380 This frame number 20 ACK that we see, it is acknowledging receipt of this bundle segment. 241 00:26:48,750 --> 00:26:56,000 This ACK down here on frame 27 is going to be acknowledging this bundle segment. 242 00:26:57,510 --> 00:26:59,340 The ACK counts up. 243 00:26:59,340 --> 00:27:05,020 So if I look at frame 20, I see an acknowledgement saying ACK length 4096. 244 00:27:05,020 --> 00:27:09,420 That was how much data was in the first bundle segment. 245 00:27:09,420 --> 00:27:20,900 I go to the next ACK and it says now I'm ACKing up to 8192 bytes because it's now acknowledging the second bundle segment. 246 00:27:20,900 --> 00:27:24,180 We'll see the next ACK coming up right here. 247 00:27:24,180 --> 00:27:27,860 This ACK is acknowledging the third bundle segment. 248 00:27:27,860 --> 00:27:37,720 So this guy is acknowledging this bundle segment, which of course includes those packets. 249 00:27:38,440 --> 00:27:43,920 And we can see that it's counted up to 12,288. 250 00:27:43,920 --> 00:27:53,240 And then we have the last ACK here, which is counting up also the very last bundle segment. 251 00:27:55,340 --> 00:28:02,700 It can be sort of confusing to see what's happening, especially when we have Wireshark's reassembly feature built into it. 252 00:28:02,700 --> 00:28:08,580 But what I did was I made a little TCP spreadsheet that goes through what's happening here. 253 00:28:08,580 --> 00:28:16,280 We have bundle segment A, bundle segment B, bundle segment C, bundle segment D there. 254 00:28:16,360 --> 00:28:21,600 And these are the frames required and the amount of data in each of those frames. 255 00:28:21,600 --> 00:28:24,340 And we add the data up in the bundle segment. 256 00:28:24,340 --> 00:28:34,440 We subtract 3 for the TCP convergence layer overhead, and that leaves us with the actual segment of data, the amount of data in there. 257 00:28:34,440 --> 00:28:36,600 Same thing here on the second one. 258 00:28:36,600 --> 00:28:39,700 It required four packets to get this across. 259 00:28:40,000 --> 00:28:44,760 Subtract the TCP CL overhead, and we're at 4096 here. 260 00:28:45,580 --> 00:28:48,440 Another 4096 bundle segment. 261 00:28:48,440 --> 00:28:51,200 And then the last one isn't quite as long. 262 00:28:51,200 --> 00:28:56,840 So I'll bring that back in in a moment when we talk about the bundle header itself. 263 00:28:58,700 --> 00:29:05,720 So all of that was the bundle being transferred from 10.0.0.1 to 10.0.0.3. 264 00:29:05,720 --> 00:29:14,480 And then all of a sudden we see 10.0.0.3 transferring this data over to 10.0.0.4. 265 00:29:16,160 --> 00:29:17,700 And the same thing. 266 00:29:17,700 --> 00:29:21,060 We have data, data, data, data. 267 00:29:21,420 --> 00:29:28,180 Interestingly enough, we have some acts that show up later, but for something else. 268 00:29:30,060 --> 00:29:39,920 So when we look at this, let's reassemble what is being transferred across this network as this bundle is being relayed. 269 00:29:39,920 --> 00:29:53,140 We can go into any one of the Stream 1 packets and just right mouse click on the frame in the packet list pane and select Follow TCP Stream. 270 00:29:53,440 --> 00:29:59,220 This is the data that is being transferred by this bundle. 271 00:29:59,580 --> 00:30:08,080 At the top of this bundle, you have these at signs and those are Keep Alives. 272 00:30:08,580 --> 00:30:16,040 So when you click on those, you can see, you can click and that Wireshark will take you to the Keep Alive packets in the background. 273 00:30:16,330 --> 00:30:25,080 What is following that immediately, the next three bytes, is actually the TCP Convergence Layer for the very first bundle. 274 00:30:25,640 --> 00:30:28,900 After that, we have a Bundle Header. 275 00:30:29,540 --> 00:30:32,680 And after that, this is all the Bundle Header. 276 00:30:32,680 --> 00:30:37,960 And then after that, we have the Payload Header. 277 00:30:39,160 --> 00:30:51,560 So, when we look at our segments going across, we have a Bundle Header that is applied only on the first bundle segment. 278 00:30:52,480 --> 00:30:59,120 Every single one of these bundle segments, though, starts with a TCP Convergence Layer Header. 279 00:30:59,520 --> 00:31:03,900 That's how we know it's the beginning of a bundle segment. 280 00:31:04,320 --> 00:31:13,200 The very first bundle will be followed by a Bundle Header, and then it will be followed by a Payload Header. 281 00:31:13,660 --> 00:31:18,520 So these are the header structures that you would see in something like this. 282 00:31:18,520 --> 00:31:27,040 We need to have that TCP CL Header in there because that provides us with the interface between TCP and the Bundle Protocol. 283 00:31:27,040 --> 00:31:30,480 It's kind of the shim between the two of them. 284 00:31:31,940 --> 00:31:40,200 In this slide, I'm showing you the amount of data that is carried in each one of these TCP segments. 285 00:31:41,180 --> 00:31:45,720 And when we add those up, these are the payload values. 286 00:31:45,720 --> 00:31:55,760 And when you look at the X, we just count up from 4096, then we count up from there until we get to our final value. 287 00:31:56,580 --> 00:32:01,460 Let me just finish up by taking you into the Bundle Header for a moment. 288 00:32:03,400 --> 00:32:11,360 We're going to go all the way down here to... let's pull frame number 32. 289 00:32:11,760 --> 00:32:25,140 This is the last frame of the bundle after it has been forwarded to... oh, wait... nope, that's not the one I want. 290 00:32:25,140 --> 00:32:32,020 I want to go up to the first... hang on, I've got a filter on there, no wonder. 291 00:32:33,840 --> 00:32:38,800 Let's go to... it doesn't matter which one of the red packets we go to. 292 00:32:38,920 --> 00:32:42,420 They'll basically have this very similar information in them. 293 00:32:42,420 --> 00:32:45,620 I'm going to go to this frame 46, let's say. 294 00:32:45,620 --> 00:32:53,580 That is the final packet of the bundle after it's been forwarded to 10.0.0.4. 295 00:32:53,580 --> 00:33:01,260 And let's go into the Bundle Header... and let me bring the Bundle Header up in that top window. 296 00:33:01,260 --> 00:33:02,120 There we go. 297 00:33:02,640 --> 00:33:05,640 There are some strange things about the Bundle Header here. 298 00:33:05,640 --> 00:33:14,080 Like for example, one of the big things that catches people is that this Bundle Header length field does not include the whole entire Bundle Header. 299 00:33:14,080 --> 00:33:18,700 It includes only the fields that follow the Bundle Header length field. 300 00:33:18,700 --> 00:33:26,120 So the Bundle Header is actually 49 bytes. 301 00:33:26,740 --> 00:33:33,800 And then the Payload Header is another 4 bytes. 302 00:33:33,800 --> 00:33:43,400 So this packet is telling me the last packet of each of the Bundle Segments. 303 00:33:43,400 --> 00:33:50,240 And then I can see down here, this is the amount of payload. 304 00:33:50,240 --> 00:33:54,880 Now this is different than the final ACK. 305 00:33:54,880 --> 00:33:59,500 So if I come up here, and let me just show you what I'm talking about here. 306 00:33:59,500 --> 00:34:12,060 This ACK right here that we saw, this ACK says that the amount of payload is 15,272 bytes. 307 00:34:12,060 --> 00:34:18,920 Sure enough, that's what it is if we add up all of the payload from each of the Bundle Segments. 308 00:34:19,560 --> 00:34:31,240 But when we look inside of a Bundle Header to see how much payload it thinks has crossed the network, it's giving us a different value. 309 00:34:31,240 --> 00:34:33,660 It's giving us 15,219. 310 00:34:33,660 --> 00:34:42,220 And the way it gets there is we have to subtract out the 49 bytes of the Bundle Header plus the 4 bytes of the Payload Header. 311 00:34:42,220 --> 00:34:49,080 We've got to get rid of 53 bytes from the extra Payload Headers and Bundle Headers at the front. 312 00:34:49,080 --> 00:34:52,960 So that's how we get to that particular number. 313 00:34:53,500 --> 00:35:15,460 So I've shown you how we can add columns, I've shown you how we can add buttons into Wireshark, and I've shown you how we can add coloring rules into Wireshark to make analyzing the Bundle Protocol and the TCP Convergence Layer Protocol a little bit easier.