[00:05.830 --> 00:10.950]  Hi, this is Laura Chappell and welcome to this video on Deep Space Networking Traffic
[00:10.950 --> 00:12.070]  Analysis.
[00:12.510 --> 00:18.290]  In this video I'm going to show you how I open up a trace file inside of Wireshark and
[00:18.290 --> 00:24.090]  begin the process of customizing Wireshark for Deep Space Networking Traffic Analysis.
[00:24.130 --> 00:29.410]  And we'll go through and learn about the Bundle Protocol and we'll learn about the TCP Convergence
[00:29.410 --> 00:30.450]  Layer.
[00:30.450 --> 00:33.090]  So let's go over to Wireshark and get started.
[00:33.690 --> 00:41.250]  In Wireshark I've opened up the trace file depicting the Deep Space Networking Traffic.
[00:41.250 --> 00:48.750]  Now we're talking about Delay and Disruption Tolerant Networking here, or DTN we simply
[00:48.750 --> 00:50.650]  refer to it as.
[00:50.650 --> 00:58.270]  And in this scenario we have a host that is sending a bundle of data in bundle segments
[00:59.230 --> 01:03.650]  to another host to be relayed to a third host.
[01:03.730 --> 01:06.250]  So let's see what we have in this trace file.
[01:06.250 --> 01:11.870]  First of all we have some traffic that doesn't have anything to do with our DTN communications.
[01:11.870 --> 01:16.190]  It's this OSPF traffic. So I'm going to get that out of the way.
[01:17.430 --> 01:21.690]  Now what we're left with are some interesting packets here.
[01:21.690 --> 01:28.110]  First of all, these top packets that you see, they're UDP packets. They're kind of sprinkled
[01:28.110 --> 01:29.470]  throughout the trace file.
[01:29.470 --> 01:36.430]  If you were to select one of those packets and look down in the packet bytes window,
[01:36.430 --> 01:41.850]  what you would see is in the data portion it appears that we have a host that is announcing
[01:41.850 --> 01:45.570]  its DTN endpoint ID.
[01:45.570 --> 01:53.010]  So 10.0.0.1 is announcing that its endpoint ID is N1.
[01:53.330 --> 01:55.210]  Kind of like its name.
[01:55.390 --> 02:02.610]  On the second packet there we have 10.0.0.2 announcing its endpoint ID as N2.
[02:02.610 --> 02:09.810]  And the next packet 10.0.0.3 announcing its endpoint ID as N3.
[02:09.810 --> 02:17.850]  Alright, that information right there is very interesting but it's not a data transfer process.
[02:17.850 --> 02:19.870]  That is just an announcement.
[02:19.870 --> 02:25.010]  What we're interested in are the TCP CL packets.
[02:25.010 --> 02:33.030]  So frame number 7 there is the first time we see a TCP Convergence Layer packet.
[02:33.030 --> 02:35.570]  And this is just a keepalive.
[02:35.570 --> 02:43.450]  By looking at these keepalives we can get a general idea of which hosts can see which hosts.
[02:43.450 --> 02:50.390]  So in frame number 7 we have 10.0.0.3 sending a keepalive to .4.
[02:50.390 --> 02:54.010]  In the next packet we have .1 sending a keepalive to 3.
[02:54.410 --> 02:57.590]  In packet 9 we have 3 sending a keepalive to 1.
[02:57.690 --> 03:05.390]  And then a little bit further on we see in packet 19 we have .2 sending a keepalive to 4.
[03:05.390 --> 03:07.810]  Alright, we can build a picture from this.
[03:08.030 --> 03:14.490]  This is what we know so far. It appears that we have 4 hosts.
[03:15.770 --> 03:22.010]  And based on the keepalives we can see which hosts are talking to which hosts.
[03:22.010 --> 03:30.110]  So we can see based on the keepalive that .1 can see .02, .2 can see 4, 4 can see 3,
[03:30.110 --> 03:31.210]  3 can see 1.
[03:31.210 --> 03:34.530]  But we don't see any keepalives going between .1 and .4.
[03:34.530 --> 03:37.770]  We don't see any keepalives between .2 and .3.
[03:37.770 --> 03:41.090]  So perhaps we have something in the way between those two hosts.
[03:41.090 --> 03:43.290]  It could be something like a planet.
[03:43.530 --> 03:49.670]  So here I have a picture, one of the various pictures of Venus with a color filter on it.
[03:49.710 --> 03:51.830]  Now let's go back to the trace file.
[03:53.170 --> 03:57.830]  So let's take a look at when data actually begins to be sent here.
[03:57.830 --> 04:03.970]  We see an awful lot of those endpoint ID announcements and we see a bunch of keepalives and we see
[04:03.970 --> 04:07.390]  some acknowledgments for those keepalives.
[04:08.950 --> 04:16.130]  When we get down to frame number 57, that's the first time we see a larger length frame
[04:16.130 --> 04:19.350]  that probably has some data in it.
[04:19.350 --> 04:26.090]  So let's create a profile in Wireshark and we'll begin the customization process to help
[04:26.090 --> 04:29.510]  us analyze deep space networking traffic.
[04:30.030 --> 04:35.970]  So in the bottom right hand corner on the status bar in Wireshark, it says Profile Default.
[04:35.970 --> 04:42.670]  I'm going to right mouse click on that column there on the bottom and say New and I'm going
[04:42.670 --> 04:50.230]  to name this profile DTN Example and I'll say OK.
[04:51.170 --> 04:56.550]  Now Wireshark takes me back to the default settings for profiles and this font is way
[04:56.550 --> 04:57.470]  too small.
[04:57.470 --> 04:59.370]  There's no way I'll be able to see that.
[04:59.370 --> 05:05.110]  So I'm going to zoom in here using the enlarge button on the main toolbar until I get to
[05:05.250 --> 05:07.330]  a font size that I like.
[05:08.110 --> 05:12.330]  Now with all of my profiles, I always add one special column.
[05:12.330 --> 05:17.190]  I like to have it up with all the work that I do analyzing traffic.
[05:17.490 --> 05:23.510]  And that column is one that will tell me the conversation numbers in the trace file.
[05:23.510 --> 05:28.510]  Wireshark numbers all the UDP conversations and it numbers all the TCP conversations.
[05:29.130 --> 05:34.150]  It starts numbering each of them at zero and they are exclusive of each other.
[05:35.030 --> 05:40.770]  I'm going to go into the very first packet in here and inside the UDP header, there is
[05:40.910 --> 05:43.310]  a field called the Stream Index field.
[05:43.410 --> 05:47.250]  And I want to add this as a column.
[05:47.250 --> 05:52.030]  To add a field as a column, you simply right mouse click on that field and say Apply as
[05:52.030 --> 05:52.870]  column.
[05:53.270 --> 05:58.750]  I'm going to right mouse click on that column heading and choose to align center for the
[05:58.750 --> 06:00.530]  contents of that column.
[06:00.850 --> 06:05.590]  Now we've started creating this great column, but we're not quite finished yet.
[06:05.590 --> 06:09.730]  Because our TCP traffic is not showing up with a stream index number.
[06:09.730 --> 06:14.550]  We've only told Wireshark to add a stream index column for UDP.
[06:14.550 --> 06:19.190]  So I'm going to right mouse click on that column header, and I'm going to choose to
[06:19.190 --> 06:20.590]  edit the column.
[06:21.290 --> 06:28.330]  And I can see right here that the field that it's based on is udp.stream and I'm going
[06:28.330 --> 06:32.010]  to add on to this to say or tcp.stream.
[06:32.190 --> 06:38.430]  Doesn't matter if you do tcp.stream or udp.stream or this direction, doesn't matter, either
[06:38.430 --> 06:39.670]  way that will work.
[06:39.670 --> 06:41.190]  And I'm going to say OK.
[06:41.770 --> 06:42.890]  There we go.
[06:43.130 --> 06:47.950]  Now, as conversations are intertwined, it's easier for me to see which conversation I'm
[06:47.950 --> 06:53.250]  currently working in because I have the conversation number on the left hand side.
[06:56.850 --> 07:02.310]  So the next thing I want to do is I want to pull out the most active conversations in
[07:02.310 --> 07:03.490]  this trace file.
[07:03.490 --> 07:09.690]  I'm going to go up to statistics and conversations, and I'm interested in the most active conversations
[07:09.690 --> 07:11.730]  based on the TCP layer.
[07:12.190 --> 07:19.490]  I'm going to sort based on the byte count from high to low, and there I can see I have
[07:19.490 --> 07:22.410]  two conversations of interest here.
[07:22.410 --> 07:24.570]  These top two are what I want to look at.
[07:24.570 --> 07:26.590]  That's data flowing.
[07:27.530 --> 07:32.530]  So I'm going to right mouse click on the very first line here, which is traffic between
[07:32.530 --> 07:34.470]  .3 and .1.
[07:34.850 --> 07:39.430]  I'm going to right mouse click and prepare a filter based on the selected value going
[07:39.430 --> 07:40.770]  in both ways.
[07:41.990 --> 07:45.770]  And then I'm going to go to the second line, and I'm going to right mouse click, prepare
[07:45.990 --> 07:46.730]  a filter.
[07:46.730 --> 07:52.470]  And this time I'm going to say or selected, going in both directions.
[07:53.390 --> 08:00.670]  Wireshark builds the filter for me in the background, and I can see exactly what this
[08:00.670 --> 08:03.890]  filter is based on, the IP addresses that it's based on.
[08:04.450 --> 08:07.290]  And I'll go ahead and I'll just apply that filter now.
[08:07.610 --> 08:13.030]  So I have two conversations, the top two conversations showing in this trace file.
[08:13.890 --> 08:21.050]  I'm going to go to file, and I'm going to save this as a separate trace file now.
[08:21.050 --> 08:23.170]  Just these two conversations.
[08:23.750 --> 08:31.890]  I'll go to file, export specified packets, and I'm going to call this DTN example.
[08:34.710 --> 08:39.410]  Now I'm going to open up that trace file called DTN example, because by default, Wireshark
[08:39.410 --> 08:42.570]  only saves the filtered packets.
[08:42.570 --> 08:44.670]  So here we go.
[08:44.970 --> 08:47.510]  Now we have some Keep Alive segments.
[08:48.550 --> 08:51.950]  Let's take a look down in the packet details window.
[08:52.710 --> 08:57.370]  Here we can see we have an Ethernet header, an IP header, a TCP header, and then after
[08:57.370 --> 09:05.030]  the TCP header, we have the DTN, TCP Convergence Layer Protocol, or TCPCL.
[09:05.030 --> 09:11.070]  It has its own header, and for Keep Alives, all we have is this single little field here
[09:11.070 --> 09:13.410]  saying that it is a Keep Alive.
[09:13.410 --> 09:17.590]  I want my Keep Alives to kind of melt into the background here, so I'm going to set up
[09:17.750 --> 09:23.430]  a coloring rule to change the way these show up in the packet list pane, so they kind of
[09:23.430 --> 09:24.690]  melt away.
[09:24.690 --> 09:27.690]  I also don't need my capture filter anymore.
[09:28.170 --> 09:33.990]  So in the detail window, I'm going to right mouse click on this Keep Alive packet, and
[09:33.990 --> 09:39.010]  I'm going to colorize this with a filter and create a new coloring rule.
[09:39.990 --> 09:46.370]  There's the syntax put in there for this coloring rule, and I'm just going to call it TCPCL
[09:46.950 --> 09:48.310]  Keep Alive.
[09:49.790 --> 09:54.110]  On the bottom of this coloring rules window, I'm going to click the background button,
[09:54.110 --> 10:01.450]  and I'm going to change the background color to sort of a washed out grayish color, let's
[10:01.450 --> 10:02.230]  say.
[10:03.270 --> 10:05.910]  I'll click OK and OK.
[10:07.630 --> 10:13.770]  Now, those Keep Alives have their own background color of this gray showing up.
[10:15.610 --> 10:21.310]  The next thing I want to do is I want to look for anywhere where it says Bundle Protocol,
[10:21.310 --> 10:27.710]  and I should expand the protocol column so you can see what's marked as TCPCL.
[10:28.390 --> 10:37.130]  Frame number 14 shows up, and in the info column it says Bundle TCPCL Segment, TCP Segment
[10:37.130 --> 10:39.810]  of a Reassembled Protocol Data Unit.
[10:39.810 --> 10:45.090]  Wireshark's TCP Reassembly function is on, and we'll talk about how that affects the
[10:45.090 --> 10:47.130]  view in just a little bit.
[10:47.370 --> 10:55.350]  But if we look inside of frame 14, I'm going to move this up, what we can see is we can
[10:55.350 --> 11:01.330]  see that we have the TCP header, and then right after that, Wireshark is telling us
[11:01.330 --> 11:10.150]  that three different segments have been reassembled to create this bundle segment.
[11:10.810 --> 11:16.310]  Let's stop for a moment and let me show you how bundles relate to bundle segments, which
[11:16.310 --> 11:19.070]  relates to TCP segments.
[11:19.970 --> 11:27.930]  So the Bundle Protocol is essentially an application, and you would have some other application
[11:27.930 --> 11:29.190]  that uses it.
[11:29.190 --> 11:33.990]  So let's say you wanted to do FTP across the galaxy.
[11:33.990 --> 11:34.950]  You could do that.
[11:34.950 --> 11:39.410]  You would type in your FTP commands, but that command would go through the Bundle Protocol
[11:39.410 --> 11:41.490]  to transfer data.
[11:41.510 --> 11:46.050]  So we would have a bundle here of data, and bundles need to be transferred around.
[11:46.050 --> 11:53.670]  It could be scientific information, it could be video, it could be pictures of the surface
[11:54.090 --> 11:56.610]  of a planet or something like that, it doesn't matter.
[11:56.610 --> 12:02.870]  You have this big bundle of data, and the Bundle Protocol is a store-and-forward protocol.
[12:02.870 --> 12:08.490]  Again, it's covered in RFC 5050 if you want to go look up some information about this.
[12:08.750 --> 12:15.510]  But when a bundle of data is going to a target system, it can be split up into bundle segments,
[12:15.510 --> 12:18.010]  and that is what we see in this trace file.
[12:18.090 --> 12:22.570]  In this trace file, the bundle that is being transferred from the first host to the relay
[12:22.570 --> 12:26.890]  has split the bundle up into four different segments.
[12:27.010 --> 12:32.610]  When we look at it on the cabling system, it's really strange because we're so used
[12:32.610 --> 12:39.410]  to an application sending down a certain amount of data, and then the TCP segments go all
[12:39.410 --> 12:41.330]  the way to the end of the data and stop.
[12:41.390 --> 12:44.530]  That's not the way it's done with the Bundle Protocol.
[12:44.530 --> 12:51.910]  A TCP segment may have some data from Bundle Segment A, and it may have some data from
[12:51.910 --> 12:54.910]  Bundle Segment B inside of it.
[12:56.250 --> 13:04.030]  So you can see that if this first bundle segment is going across the network, it's got a TCP
[13:04.030 --> 13:09.050]  segment, another TCP segment, and then part of the third TCP segment is part of Segment
[13:09.050 --> 13:09.790]  A.
[13:09.790 --> 13:16.690]  And then Bundle Segment B goes out, but part of Bundle Segment B is sitting in the third
[13:16.690 --> 13:18.590]  TCP segment here.
[13:18.630 --> 13:23.790]  And then we have a TCP segment devoted to Bundle Segment B, another one, and then we
[13:23.790 --> 13:28.950]  only needed part of another TCP segment, but why stop the TCP segment and create a new
[13:28.950 --> 13:29.570]  one?
[13:29.570 --> 13:30.110]  Nope.
[13:30.110 --> 13:36.110]  We will have Bundle Segment C, and it starts in the middle of a TCP segment.
[13:36.110 --> 13:42.010]  Literally, you will see a header inside of this segment right here, indicating that this
[13:42.010 --> 13:44.050]  new bundle is coming up.
[13:44.710 --> 13:47.530]  Same thing with the final bundle segment.
[13:47.970 --> 13:52.710]  There will be a header right at the beginning of this bundle segment saying that this is
[13:52.710 --> 13:54.930]  the start of a new set.
[13:56.750 --> 14:05.210]  So, let's go take a look at these bundle segments as they show up delivered by TCP segments.
[14:06.850 --> 14:13.190]  So in the Info column, we see on frame number 14, it says Bundle TCP CL Segment, and when
[14:13.190 --> 14:19.350]  we click on it, we have an indication here of which packets were required to put together
[14:19.350 --> 14:22.830]  this first bundle segment.
[14:22.830 --> 14:26.310]  Frame number 11, frame 13, and frame 14.
[14:26.310 --> 14:32.330]  And the numbers in parentheses are how much data fits into this bundle segment.
[14:34.350 --> 14:36.170]  Now we can also see below this.
[14:36.170 --> 14:44.590]  This is the TCP Convergence Header, and unlike the TCP CL Keep Alive, there are more fields.
[14:44.590 --> 14:49.090]  There are a total of four fields in this TCP Convergence Header.
[14:49.090 --> 14:54.790]  So we have the packet type field, so this is data.
[14:55.030 --> 14:58.410]  Then we have, this is indented, so don't get stuck on this.
[14:58.410 --> 14:59.930]  These are not new fields.
[15:00.050 --> 15:03.250]  This is the summary line for these two below.
[15:03.250 --> 15:08.350]  There is one bit that would indicate if this is the start of the entire bundle, and there's
[15:08.350 --> 15:13.930]  another bit that indicates if this would be the last packet of the entire bundle.
[15:13.930 --> 15:22.470]  And then we have a line that tells us how large that TCP bundle segment is.
[15:22.470 --> 15:25.910]  That is a bundle segment length.
[15:29.100 --> 15:36.040]  So let's do some customization of Wireshark based on these fields.
[15:36.340 --> 15:40.960]  Number one, I want to take the packet type field, and I'm going to right mouse click
[15:40.960 --> 15:43.020]  on this and apply this as a column.
[15:43.260 --> 15:43.980]  There we go.
[15:43.980 --> 15:48.780]  It's easy now to see the difference between Keep Alives There and where data packets are.
[15:48.780 --> 15:53.880]  And then I also want to do the same thing for Segment Contains Start of Bundle.
[15:53.920 --> 15:59.560]  I'm going to right mouse click here, and this is the Start of Bundle packet, so I'm going
[15:59.560 --> 16:03.420]  to apply this as a column, and we can see that it's true.
[16:03.640 --> 16:05.740]  I'm going to center align that.
[16:07.100 --> 16:13.600]  And then this next field, Segment Contains End of Bundle, I'm going to add that as a
[16:13.600 --> 16:16.700]  column, and I'll center align that.
[16:17.060 --> 16:23.320]  Now it's pretty easy to look through the trace file and see which packets are the start of
[16:23.320 --> 16:31.420]  the bundle, and then farther on we'll be able to see which packets are the end of the bundle.
[16:31.420 --> 16:38.880]  That's the end of the entire bundle, not the bundle segment, but the bundle itself.
[16:38.880 --> 16:44.620]  To make it even easier to detect these, I'm going to set up two coloring rules.
[16:44.640 --> 16:49.660]  I'm going to set up one coloring rule that turns all packets that are the start of the
[16:49.660 --> 16:54.520]  bundle a green color and then the end of the bundle red.
[16:54.820 --> 16:59.740]  So in frame number 14 I'm going to right mouse click on this line that says Segment Contains
[16:59.740 --> 17:08.780]  Start of Bundle, and I'm going to choose Colorize with Filter, New Coloring Rule, and it's
[17:08.780 --> 17:16.520]  already set to a 1 because this is the start, so I'm going to just name this Start of Bundle,
[17:16.520 --> 17:24.380]  and then for the background I'm going to choose sort of a lime green-ish.
[17:27.720 --> 17:34.160]  Now by setting that coloring up, it's very easy for me to detect where the start of the
[17:34.160 --> 17:36.280]  bundles are in the trace file.
[17:36.280 --> 17:38.680]  Three of the packets should have matched that.
[17:38.780 --> 17:40.320]  Here's another thing we can do.
[17:40.320 --> 17:46.700]  We can right mouse click on that field and just simply prepare a filter based on the
[17:46.700 --> 17:47.980]  selected value.
[17:47.980 --> 17:55.360]  That just puts that filter to detect the start of bundle packets up in my display filter
[17:55.360 --> 17:56.300]  area.
[17:56.500 --> 18:00.920]  And on the far right hand side of the display filter area there's a little plus there.
[18:01.240 --> 18:05.180]  I'm going to click that plus and I'm going to turn this into a button.
[18:05.280 --> 18:09.640]  I'm going to give the button a label which is going to be S-Bundle.
[18:09.640 --> 18:12.500]  That to me means Start of Bundle.
[18:12.900 --> 18:14.400]  I'll say OK.
[18:14.980 --> 18:16.020]  Now I have a button.
[18:16.020 --> 18:22.580]  When I click on it, any packets that have the Start of Bundle bit set to a 1 will show
[18:22.580 --> 18:23.360]  up.
[18:24.000 --> 18:27.300]  Let me clear out the filter that the button just applied.
[18:27.920 --> 18:32.280]  I want to do the same thing with the End of Bundle.
[18:32.280 --> 18:33.880]  I want to give it a color.
[18:33.880 --> 18:37.620]  I'm going to give it a vibrant red and then I'll make a button so I can easily detect
[18:37.620 --> 18:40.780]  the End of Bundle and just show those packets.
[18:40.860 --> 18:44.680]  Now this packet has the End of Bundle bit set to a 0.
[18:44.680 --> 18:48.580]  I'm going to change that to a 1 when I do my coloring rule.
[18:48.580 --> 18:52.740]  I'm going to change that to a 1 when I do my display filter button.
[18:53.120 --> 18:59.880]  So I'm going to right mouse click on this packet, colorize with a filter, new coloring
[18:59.880 --> 19:04.460]  rule, name it End of Bundle.
[19:05.420 --> 19:09.600]  And I'm going to give it a background color of this vibrant red.
[19:09.880 --> 19:12.420]  I'll say OK, OK.
[19:12.640 --> 19:15.320]  So now it's very easy.
[19:16.740 --> 19:19.020]  Oh, I forgot to change the number.
[19:19.500 --> 19:22.920]  Well, it's good for you to see how to edit coloring rules.
[19:22.940 --> 19:27.040]  To edit a coloring rule, we go to View, Coloring Rules.
[19:27.280 --> 19:30.760]  And I wanted to change this to a 1 at the end.
[19:31.400 --> 19:32.900]  There we go.
[19:34.760 --> 19:41.200]  Alright, so now we can see there's the start of a bundle, there's the end of a bundle.
[19:41.360 --> 19:47.120]  There's a start of a bundle, and there's the end of a bundle right here.
[19:47.600 --> 19:55.180]  The first start of bundle we see going from 10.0.0.1 to 10.0.0.3.
[19:55.180 --> 20:03.740]  So the first thing we see in here is we see a bundle being transferred from .1 to .3 in
[20:03.740 --> 20:05.140]  Bundle Segments.
[20:05.320 --> 20:14.380]  After that bundle is done, right there, then down on frame 37, we see another bundle starting.
[20:14.380 --> 20:17.460]  And this bundle is from .3 to .4.
[20:17.460 --> 20:21.560]  This is the first bundle being forwarded on by .3.
[20:21.560 --> 20:23.780]  So it's being relayed on.
[20:25.020 --> 20:32.840]  And then we see the end of that bundle after it's been relayed.
[20:33.500 --> 20:40.580]  And the very last packet that we see here, from .3 going back to .1, it's a little strange.
[20:40.580 --> 20:42.440]  It's its own bundle.
[20:42.440 --> 20:48.520]  We can see that the start of bundle is set at true, and the end of bundle is set at true.
[20:48.520 --> 20:53.020]  First of all, I want to pop up a button up here for end of bundle.
[20:53.380 --> 20:58.480]  Well I'll use this packet since it has the end of bundle bit set on.
[20:58.900 --> 21:05.480]  I'm going to go inside the TCP Convergence Layer here, right mouse click, I'm just going
[21:05.480 --> 21:08.600]  to prepare it as a filter based on the selected value.
[21:08.960 --> 21:09.660]  There it is.
[21:09.660 --> 21:11.440]  That's what I want to build the button on.
[21:11.540 --> 21:16.240]  So I'm going to click plus and give it a name, eBundle.
[21:16.240 --> 21:18.420]  That means end of bundle to me.
[21:18.620 --> 21:23.720]  So now if I want to see the end of bundle packets only, I can click on the second button.
[21:23.720 --> 21:27.160]  I want to see the start, I can click on the first button.
[21:27.340 --> 21:29.680]  I'm going to go ahead and clear this out.
[21:30.040 --> 21:37.080]  Now you'll notice that after this bundle has been relayed from 3 to 4, there's this packet,
[21:37.080 --> 21:43.240]  this strange packet here, where it has the start and end of bundle bits set on.
[21:43.240 --> 21:45.820]  That means it's its own little bundle.
[21:46.140 --> 21:50.780]  And this is actually a reporting packet.
[21:50.900 --> 21:54.020]  So let's go inside of it and take a look.
[21:54.420 --> 22:02.480]  Let me bring up this, let's see, I'm going to bring this sort of up so we see it up on
[22:02.480 --> 22:03.440]  top.
[22:05.360 --> 22:08.760]  And it is frame 49 we're interested in.
[22:08.760 --> 22:14.420]  And when we look inside of frame number 49, we see the TCP convergence layer indicating
[22:14.420 --> 22:17.120]  it's the start of a bundle and the end of a bundle also.
[22:17.120 --> 22:19.700]  So we're obviously not transferring a bunch of data here.
[22:19.900 --> 22:23.900]  And then we'll see the primary bundle header.
[22:24.880 --> 22:30.420]  And if we look a little bit further in here, we will see a payload header.
[22:30.620 --> 22:34.400]  And beyond this we have the administrative record.
[22:34.400 --> 22:40.580]  So this is indicating right here that this is a bundle status report.
[22:40.580 --> 22:42.960]  That's the purpose of this packet.
[22:43.480 --> 22:49.820]  I don't want this packet to be colored red just because it hit the end of bundle coloring.
[22:49.820 --> 22:52.660]  I want this packet to have its own coloring.
[22:52.660 --> 22:57.740]  So I'm going to right mouse click on the line that says administrative record type, bundle
[22:57.740 --> 23:04.080]  status report, and I'm going to choose to colorize this with a filter, make a new coloring
[23:04.080 --> 23:11.900]  rule, there's that line, admin record type 1, and I'm just going to say that this is
[23:11.900 --> 23:14.160]  the admin report.
[23:14.620 --> 23:25.520]  I'm going to turn the background yellow for this one, say OK, and now there we go.
[23:25.520 --> 23:28.960]  This is the admin report.
[23:28.960 --> 23:35.960]  And that admin report is being sent from .3 to .1 to say that I successfully delivered
[23:35.960 --> 23:38.700]  the bundle on for you.
[23:39.180 --> 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.
[23:46.090 --> 23:52.900]  In frame number 14, Wireshark says this is a bundle segment.
[23:53.820 --> 23:59.080]  And sure enough, if we look inside, we can see the data packets that were required to
[23:59.080 --> 24:04.620]  make up this bundle segment, packet 11, packet 13, and packet 14, and we can see the amount
[24:04.620 --> 24:09.760]  of data in each of those segments to make up, in each of those TCP segments to make
[24:09.760 --> 24:11.120]  up this bundle segment.
[24:11.220 --> 24:17.320]  And then when we look down at frame number 18, again on the right hand side, it says
[24:17.320 --> 24:20.380]  bundle TCP CL segment.
[24:20.640 --> 24:29.840]  And if we look inside of that frame, we can see which TCP segments were required to make
[24:29.840 --> 24:32.000]  up this bundle segment.
[24:32.000 --> 24:34.540]  And there's the weird one right there.
[24:35.100 --> 24:43.140]  So some of the data that's in packet number 14 is part of bundle segment A, whereas some
[24:43.140 --> 24:47.060]  of the data in packet 14 is part of bundle segment B.
[24:47.060 --> 24:48.680]  The second bundle segment.
[24:49.170 --> 24:50.800]  It's very interesting.
[24:50.840 --> 24:53.220]  It's a bit of a different protocol.
[24:54.120 --> 25:02.440]  And if we keep looking down here, in frame number 26, frame number 26 is listed here
[25:02.440 --> 25:06.160]  as bundle TCP CL segment.
[25:06.160 --> 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.
[25:14.160 --> 25:19.520]  Let's clear that out and let's go beyond that to the next bundle segment.
[25:20.040 --> 25:21.920]  Oh, maybe I didn't, I don't remember.
[25:23.280 --> 25:32.260]  So I'm clicking on frame number 26, and in frame 26, oh it just hadn't clicked, I didn't
[25:32.260 --> 25:38.020]  click on frame 26 before, it was still selecting frame number 18.
[25:38.280 --> 25:43.840]  So now I'm on frame number 26 that says some of its data is in frame number 18, some of
[25:43.840 --> 25:47.760]  it is in 23, 24, and 26.
[25:50.660 --> 25:58.960]  And then the last bundle segment is actually the one that finishes up the whole bundle.
[25:58.960 --> 26:07.660]  So frame number 32, we can see its data, and if we look down here we can see exactly which
[26:07.660 --> 26:14.020]  frames were required, which TCP segments were required to get this bundle segment across.
[26:14.760 --> 26:20.780]  It is pretty, it can be pretty confusing to look at this because we have bundle segments
[26:20.780 --> 26:24.840]  and then we have TCP segments, and they don't necessarily align.
[26:25.700 --> 26:28.880]  Along the way here we had some ACKs showing up.
[26:28.940 --> 26:36.000]  So here we have the first bundle segment up here, and then we have an ACK down here on
[26:36.000 --> 26:37.300]  frame number 20.
[26:37.300 --> 26:46.380]  This frame number 20 ACK that we see, it is acknowledging receipt of this bundle segment.
[26:48.750 --> 26:56.000]  This ACK down here on frame 27 is going to be acknowledging this bundle segment.
[26:57.510 --> 26:59.340]  The ACK counts up.
[26:59.340 --> 27:05.020]  So if I look at frame 20, I see an acknowledgement saying ACK length 4096.
[27:05.020 --> 27:09.420]  That was how much data was in the first bundle segment.
[27:09.420 --> 27:17.980]  I go to the next ACK and it says now I'm ACKing up to 8192 bytes because it's now acknowledging
[27:17.980 --> 27:20.900]  the second bundle segment.
[27:20.900 --> 27:24.180]  We'll see the next ACK coming up right here.
[27:24.180 --> 27:27.860]  This ACK is acknowledging the third bundle segment.
[27:27.860 --> 27:37.720]  So this guy is acknowledging this bundle segment, which of course includes those packets.
[27:38.440 --> 27:43.920]  And we can see that it's counted up to 12,288.
[27:43.920 --> 27:53.240]  And then we have the last ACK here, which is counting up also the very last bundle segment.
[27:55.340 --> 28:00.620]  It can be sort of confusing to see what's happening, especially when we have Wireshark's
[28:00.620 --> 28:02.700]  reassembly feature built into it.
[28:02.700 --> 28:08.580]  But what I did was I made a little TCP spreadsheet that goes through what's happening here.
[28:08.580 --> 28:16.280]  We have bundle segment A, bundle segment B, bundle segment C, bundle segment D there.
[28:16.360 --> 28:21.600]  And these are the frames required and the amount of data in each of those frames.
[28:21.600 --> 28:24.340]  And we add the data up in the bundle segment.
[28:24.340 --> 28:30.280]  We subtract 3 for the TCP convergence layer overhead, and that leaves us with the actual
[28:30.280 --> 28:34.440]  segment of data, the amount of data in there.
[28:34.440 --> 28:36.600]  Same thing here on the second one.
[28:36.600 --> 28:39.700]  It required four packets to get this across.
[28:40.000 --> 28:44.760]  Subtract the TCP CL overhead, and we're at 4096 here.
[28:45.580 --> 28:48.440]  Another 4096 bundle segment.
[28:48.440 --> 28:51.200]  And then the last one isn't quite as long.
[28:51.200 --> 28:56.840]  So I'll bring that back in in a moment when we talk about the bundle header itself.
[28:58.700 --> 29:05.720]  So all of that was the bundle being transferred from 10.0.0.1 to 10.0.0.3.
[29:05.720 --> 29:14.480]  And then all of a sudden we see 10.0.0.3 transferring this data over to 10.0.0.4.
[29:16.160 --> 29:17.700]  And the same thing.
[29:17.700 --> 29:21.060]  We have data, data, data, data.
[29:21.420 --> 29:28.180]  Interestingly enough, we have some acts that show up later, but for something else.
[29:30.060 --> 29:37.400]  So when we look at this, let's reassemble what is being transferred across this network
[29:37.400 --> 29:39.920]  as this bundle is being relayed.
[29:39.920 --> 29:47.580]  We can go into any one of the Stream 1 packets and just right mouse click on the frame in
[29:47.580 --> 29:53.140]  the packet list pane and select Follow TCP Stream.
[29:53.440 --> 29:59.220]  This is the data that is being transferred by this bundle.
[29:59.580 --> 30:08.080]  At the top of this bundle, you have these at signs and those are Keep Alives.
[30:08.580 --> 30:13.220]  So when you click on those, you can see, you can click and that Wireshark will take you
[30:13.220 --> 30:16.040]  to the Keep Alive packets in the background.
[30:16.330 --> 30:22.460]  What is following that immediately, the next three bytes, is actually the TCP Convergence
[30:22.460 --> 30:25.080]  Layer for the very first bundle.
[30:25.640 --> 30:28.900]  After that, we have a Bundle Header.
[30:29.540 --> 30:32.680]  And after that, this is all the Bundle Header.
[30:32.680 --> 30:37.960]  And then after that, we have the Payload Header.
[30:39.160 --> 30:47.020]  So, when we look at our segments going across, we have a Bundle Header that is applied only
[30:47.020 --> 30:51.560]  on the first bundle segment.
[30:52.480 --> 30:58.100]  Every single one of these bundle segments, though, starts with a TCP Convergence Layer
[30:58.100 --> 30:59.120]  Header.
[30:59.520 --> 31:03.900]  That's how we know it's the beginning of a bundle segment.
[31:04.320 --> 31:11.400]  The very first bundle will be followed by a Bundle Header, and then it will be followed
[31:11.400 --> 31:13.200]  by a Payload Header.
[31:13.660 --> 31:18.520]  So these are the header structures that you would see in something like this.
[31:18.520 --> 31:24.320]  We need to have that TCP CL Header in there because that provides us with the interface
[31:24.320 --> 31:27.040]  between TCP and the Bundle Protocol.
[31:27.040 --> 31:30.480]  It's kind of the shim between the two of them.
[31:31.940 --> 31:37.880]  In this slide, I'm showing you the amount of data that is carried in each one of these
[31:38.380 --> 31:40.200]  TCP segments.
[31:41.180 --> 31:45.720]  And when we add those up, these are the payload values.
[31:45.720 --> 31:52.680]  And when you look at the X, we just count up from 4096, then we count up from there
[31:53.160 --> 31:55.760]  until we get to our final value.
[31:56.580 --> 32:01.460]  Let me just finish up by taking you into the Bundle Header for a moment.
[32:03.400 --> 32:11.360]  We're going to go all the way down here to... let's pull frame number 32.
[32:11.760 --> 32:23.600]  This is the last frame of the bundle after it has been forwarded to... oh, wait... nope,
[32:23.600 --> 32:25.140]  that's not the one I want.
[32:25.140 --> 32:32.020]  I want to go up to the first... hang on, I've got a filter on there, no wonder.
[32:33.840 --> 32:38.800]  Let's go to... it doesn't matter which one of the red packets we go to.
[32:38.920 --> 32:42.420]  They'll basically have this very similar information in them.
[32:42.420 --> 32:45.620]  I'm going to go to this frame 46, let's say.
[32:45.620 --> 32:53.580]  That is the final packet of the bundle after it's been forwarded to 10.0.0.4.
[32:53.580 --> 33:00.700]  And let's go into the Bundle Header... and let me bring the Bundle Header up in that
[33:00.700 --> 33:01.260]  top window.
[33:01.260 --> 33:02.120]  There we go.
[33:02.640 --> 33:05.640]  There are some strange things about the Bundle Header here.
[33:05.640 --> 33:10.140]  Like for example, one of the big things that catches people is that this Bundle Header
[33:10.140 --> 33:14.080]  length field does not include the whole entire Bundle Header.
[33:14.080 --> 33:18.700]  It includes only the fields that follow the Bundle Header length field.
[33:18.700 --> 33:26.120]  So the Bundle Header is actually 49 bytes.
[33:26.740 --> 33:33.800]  And then the Payload Header is another 4 bytes.
[33:33.800 --> 33:43.400]  So this packet is telling me the last packet of each of the Bundle Segments.
[33:43.400 --> 33:50.240]  And then I can see down here, this is the amount of payload.
[33:50.240 --> 33:54.880]  Now this is different than the final ACK.
[33:54.880 --> 33:59.500]  So if I come up here, and let me just show you what I'm talking about here.
[33:59.500 --> 34:10.320]  This ACK right here that we saw, this ACK says that the amount of payload is 15,272
[34:11.120 --> 34:12.060]  bytes.
[34:12.060 --> 34:17.820]  Sure enough, that's what it is if we add up all of the payload from each of the Bundle
[34:17.820 --> 34:18.920]  Segments.
[34:19.560 --> 34:27.240]  But when we look inside of a Bundle Header to see how much payload it thinks has crossed
[34:27.240 --> 34:31.240]  the network, it's giving us a different value.
[34:31.240 --> 34:33.660]  It's giving us 15,219.
[34:33.660 --> 34:40.320]  And the way it gets there is we have to subtract out the 49 bytes of the Bundle Header plus
[34:40.320 --> 34:42.220]  the 4 bytes of the Payload Header.
[34:42.220 --> 34:48.160]  We've got to get rid of 53 bytes from the extra Payload Headers and Bundle Headers at
[34:48.160 --> 34:49.080]  the front.
[34:49.080 --> 34:52.960]  So that's how we get to that particular number.
[34:53.500 --> 35:00.780]  So I've shown you how we can add columns, I've shown you how we can add buttons into
[35:00.780 --> 35:07.580]  Wireshark, and I've shown you how we can add coloring rules into Wireshark to make analyzing
[35:07.580 --> 35:15.460]  the Bundle Protocol and the TCP Convergence Layer Protocol a little bit easier.