hpr-knowledge-base/hpr_transcripts/hpr0427.txt

Episode: 427
Title: HPR0427: Intro to Networking 
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr0427/hpr0427.mp3
Transcribed: 2025-10-07 20:20:30

---

.
The following presentation was recorded by view digital media at the inaugural South East
Linux Fest in Clemson, South Carolina on June 13, 2009.
For more information about the South East Linux Fest, visit southeastlinuxfest.org.
Thank y'all so much for coming.
I was actually, you know, a little afraid when nobody showed up because they had, you
know, Linux games and do Ubuntu kernel running right now, and I know how popular Ubuntu
is.
Anyhow, this is just a real quick primer on TCP IP for the, for the full discussion.
You'll want to check out the link provided here at www.lizeladotnet.net forward slash network
on 101.txt. The full, you know, the full things available there, and you'll get, you
know, a much greater understanding than what I can just do here.
For example, in this presentation, we won't look at a packet in its entire binary
form, although in the text file here we will.
So I basically started doing this class, I guess you would say, on IRC, because I was
kind of impressed by how many, you know, smart people just didn't know a darn thing about
the protocols you use for networking across the internet today.
You know, there's a heap of people out there that I respect a lot that know a bunch of
junk that I don't know, and, you know, they would think UDP was, you know, guaranteed
delivery, you know, just, just ridiculous stuff, or, you know, didn't understand how
a routing decision was made.
So I, you know, invented this class to sort of answer that.
There's a couple, you know, basic terms we go through.
I'm sure you're familiar with node, that's just anything that's actually on a network
is a node.
And a frame, you'll probably more commonly hear them call packets, you know, you talk
about a packet doing this or a packet doing that, but when you get down to the low level,
it's more often that you're referring to frames.
It's basically the same thing.
Oftentimes a frame is an incomplete packet or a packet that's currently being mangled
somewhere along in the stack.
Now there's a whole bunch of layers, there's actually seven in this OSI model, but we're
only really interested in five for most basic things.
That's the physical layer, the data link layer, the network layer, the transport layer,
and then the application layer.
The physical layer, it's basically anything you can kick.
And I used to say that, but now you have wireless and you can't kick there, you know, you
can't kick there waves, radio waves.
But basically the physical layer is what actually transmits a signal.
You know, usually you're talking about fiber optic cables or copper cables, but you could
also be talking about radio waves, but the physical layer is what exists in the real world
as a real thing, not as just data.
The data link layer is the first really interesting layer, the physical layer, it's kind of boring,
you know, it's just, here's this stuff, you know.
But the data link layer is what actually delivers frames or packets to other computers.
Without it, you don't get any delivery whatsoever.
And then you have the network layer, that's the first really fun when that's where all
your routing decisions are made.
That's what allows you to actually communicate with a computer through an intermediary
computer like a default gateway.
Without the network layer, you have no internet.
And that was going back in the day, that was a big failure of no veils, IPX.
You know, it just, it didn't really have any sort of way to route on the internet.
If you're familiar with that, you know, Windows, machine name, stuff like that, it's not
right, but there's no network layer there, that's why you can't connect to, I don't know,
workstation, Dell, 53X, you know, across the internet because there's no network layer.
The transport layer, this is where you start to talk about TCP or UDP, and this is the
only layer that can guarantee that your data actually arrived intact at the opposite location.
Everything else is unreliable transmission, but until you get to the transport layer,
this is where we start doing some intelligent hackery that allows us to know that the other
end receives what we see it, and that it was intact when it was received.
And the application layer is, in a nutshell, it's just the application, it's whatever actually
makes the data portion of the frame or the packet.
There's the session layer, and there's one other that's never really used as well, but
they're really usually restricted to things like multicasting, and we're just not going
to get into them because they're not of practical importance here.
All right, the first layer we're going to look into big is the physical layer.
Like we said, it can be anything from radio waves, the laser beams, the copper wire, the
fiber optics, but basically your cat-five cable is the most common.
That's what you see.
You go into a network closet or you have a switch at home or your cable modem.
There's copper cable coming out of that going to your computer because it's cheap and
it's reliable.
It costs a lot to make fiber optic cable to run short distances, so most everyone just
uses copper, cat-five, or cat-five-e, cat-six, something like that.
In the physical layer, we're just going to pay attention to cat-five here for copper
because we just don't have time to delve into fiber optics and, you know, Wi-Fi, things
like that.
But in cat-five or any sort of copper transmission, the fluctuations in vulture, fluctuations
in voltage, excuse me, I had some beers at lunch.
They register as your binary digits.
So if you look at this, what we have here is 1, 1, 0, basically the number of what?
6, that'd be 1, 2, and 4, yeah, 6.
So as you can see here on this graph, and this is not 100% accurate, but the blue line
sort of here represents your baseline.
You're no value line, I guess you would say.
If the voltage fluctuation is above that, it registers as a 1.
If it's below that, it registers as a 0.
So you have this sine wave, you know, going back and forth, basically, that determines
whether the signal is interpreted as a 1, or if it's interpreted as a 0.
It's important to remember that in the physical layer, everything is analog.
It's just interpreted digitally.
You know, there's no way to transmit 1, no way to transmit 0.
You have to transmit a voltage above a certain value, or below a certain value, and that's
interpreted as a 1, or a 0.
Now in the physical layer, you got a whole bunch of devices, your network interface cards,
repeaters, these are just basically, once you get a signal out so far, you're
starting to lose a voltage, it's called voltage drop.
You just get so much resistance from the wire.
So after you get out of certain distance, you need some sort of a peter there, that will
then, you know, up the voltage on the line, basically, so that the signal gets further
out and gets reliably delivered.
There's also hubs, we really don't use these much anymore because they suck.
It's basically like splitting one cable so that it delivers to multiple places.
You know, usually you've got a cable, it's got one end over here and one end over here.
And if you can only send between those two ends, it's not, you know, really interesting.
There's no sense in routing between just two places, you know, you don't really need
a whole lot to say, send a bob if bob's the only other person in the world, you know.
So a hub basically sort of splits that cable so it puts multiple ends on it.
We'll get into a little bit more as to why hubs suck in the next section.
The data link layer, okay, this is the very first portion that things start to get interesting.
If anybody has a question, don't raise your hand just shout, I won't get offended, you
know, just speak up, I'll stop.
The data link layer includes something that you all may have heard of, MAC addresses,
media access control, every device that, you know, operates on the data link layer has
a MAC address and it's set by the factory unless you're good and you can change it.
But anytime frame is sent out and it's destined to some other computer, it gets a source
and a destination MAC address set.
The source address, you know, the source MAC addresses, of course, your MAC address,
whichever machine's actually sending the frame and the destination address is which
everyone is going to.
That might not be its final destination, it's just the next place it's going to and we'll
see that a little bit more in the next layer when we start to talk about routing.
As we go on, you know, MAC addresses are unique, 48 bit numbers and to give you an idea,
you know, we're starting to run out of IPv4 space and that's a 32 bit number so you got
a whole another 16 bits to deal with.
So we're okay on MAC addresses, they're not a big problem.
As important to realize, the MAC address is the only address that is used to deliver
a packet or frame.
The IP address means nothing as far as where the packet actually ends up.
The IP address is just determining where to route it to and if it's on your subnet and
then ARP takes over, we'll see that a little bit later too.
This is why hubs, lands that are connected with hubs, a land is a low query network.
We got this laptop hooked up to some other laptop upstairs and there's a server and it's
all contained in this building, that would be a low query network.
If you connect that with hubs, every time one machine sends a frame, it's going to go
to every other computer on that low query network.
So every other computer has to deal with it.
Each computer that receives a frame checks the destination MAC address.
If that matches that node's MAC address, it says, hey, this frame is meant for me and
then it accepts it and sends it on up the stack.
If it doesn't, it just discards it to the bit bucket.
The frame's gone as far as that node's concerned and that's okay for small networks but when
things start to build up, you get a lot of collisions, a lot of repeated data and so
there's two things that are used at the data link layer to mitigate this.
The first is bridges.
These are kind of old school, they're not used as much anymore for their original purpose.
What you would do is you would have one hub over here on the left and one hub over here
on the right and a bridge sat in between.
The bridge makes an intelligent decision whenever it sees a frame.
It says, does this frame need to go across me?
If it does, it lets it across.
If it doesn't, it just drops it.
So if you have one machine over here connected to this hub on the left, talking to another
machine on the left, all these machines connected to the hub over here on the right, never
see that frame because the bridge right here in the middle stops it.
Same if you got machines on the right, talking to machines on the right.
The ones on the left never see it.
And that was a big performance boost because you didn't have all this replication of data.
And remember when you've got physical layers here, you're talking about having every machine
get the same binary ones and two ones and Z rows, ones and two.
Man, that would be an increase in throughput.
Great tertiary computers in here, but every machine basically has to see the same ones
and Z rows at the same time.
With bridges, you now have the ability for two machines on the left to talk to each other
at one time, while two machines on the right are talking to each other at the same time.
A switch goes a little bit further, it's sort of a combination of a hub and a bridge.
You know, hubs might have 48 ports on them.
Well, a switch is basically a hub with a bridge on every port so that whenever, you know,
let's say island and I'm plugged into one and, you know, I want to talk to a camera guy
who's plugged into two.
I can send a packet and the switch says, well, camera guy's on port two and it just sends
it down port two.
All y'all other people, 3, 3, 48, y'all don't ever see it, don't know it exists.
And in fact, y'all are able to talk to one another at the same time because the media
isn't being reserved.
The switch has, you know, intelligently handled the frame and just routed it to the one
place it needed to go.
It does this by doing an art look up and I'm not going to go into all this at this time.
And you shouldn't rely on switches to do security work because if you aren't plugged
to switch, it will either shut down entirely and not pass any frames or it will operate
as a hub depending on the making model.
So you know, just be aware just because you have a switch doesn't mean somebody can't
plug in on another port and listen to you.
It just depends on how good your switch is.
There's nothing else I can doubt share lying.
But the network layer, that's a rope here that's probably the most difficult to learn
layer but it's also the most rewarding.
This is the first place that allows you to, from one computer and, you know, one part
of the world, lies a little jolge and that's right, it's jolge, not jolge, it's jolge.
You could talk to someone in Clemson, South Carolina because it allows you to decide whether
that machine is, I guess you would say near or far, whether it's on my local area network
or whether it's not.
And then to consult a routing table and decide where to send the packet to next and allow
someone else to send it on further down the line.
Without this layer, you can only talk with your local area network.
That's why NetBewi, you know, Windows, SMB, well SMB's now done over TCP but in the days
of Windows 95, Windows 98, Windows NT, you know, you couldn't do any sort of file sharing
across a land, at least without winds because there was no way to encapsulate it.
There was no way to route it.
Frames are routed based on their destination IP address, and we shouldn't see that in the
next couple slides here.
People tend to think of the network layers, only including internet protocol, but there's
some others as well.
And some protocols like ICMP, they actually kind of straddle the network and the transport
layer.
We'll get to those in a moment.
IPv4 addresses, those are 32 bit numbers, that's two to the 32nd power possible IP addresses.
Don't make me do that math, but it's a big number.
IPv6, 128 bit numbers, that's a huge frigging number.
You know, I mean, if you took every molecule of water in the ocean and you know, the
earth is covered 75% by ocean, and you gave each water molecule a unique IP address,
you still wouldn't run out.
You know, so once we switch to IPv6, knock on wood, we won't need any more IP addresses
for at least my generation.
We're only going to discuss IPv6 here because, you know, if I actually put 128 bit number
on there, I mean, you can see what this 32 bit number here is.
I'd run out of room on the slide.
IP addresses are generally listed as four octakes.
You'll see one right here, this is probably something you're very common with.
The guy links his route or something like that, 192.168.1.1.
We split it up into four octakes.
What that means is there are four different eight bit numbers.
And with two to eight powers, 256, that allows you to do any number from zero to 255.
That's why you don't see any IP addresses like 300 dot 497.
You know, you can only go up to 255 in eight bits.
But computers don't separate it like that.
The computer will actually treat it as one 32 bit binary number.
It's not decimal, it's binary.
So actually, you know, 110, blah, blah, blah, blah, one is 192.168.1.1.
That's how the computer sees it.
Well, how any network device, whether it's a computer or a switch, whatever.
Subnating.
And we're going pretty fast.
So if y'all don't understand anything, you know, Holler.
Subnating is probably the toughest part of networking.
It used to be real easy because we were real stupid.
And we only had three possible subnets, 255.0.0.0 and, you know, 255.255.0.0 and 255.255.255.0.
And that was it.
You know, you could have either 16,000 addresses, 255,000 addresses or a million.
And that was it.
You know, there was no sort of fine tuning.
And that kind of exacerbated the problem as far as us running out of IP addresses with
IPv4 because I think forward has a couple million addresses and IBM probably has 10 or 12.
And, you know, who knows, GM goes bank, well, GM did go bankrupt.
Maybe they got a bunch of IP addresses when you get back.
So what?
Yeah, yeah, yeah.
Well, then you got the White House with a million IP addresses and who needs that?
Subnets, they're denoted basically the same way IP addresses are.
We got, you know, four optics, you know, 255.255.255.0.0.
It was probably the most common you dealt with.
But it can be any number from all zeroes to all ones.
We'll show that in a moment.
You'll also sometimes see them as masks, 192.168.1.1 slash 24.
Once you actually look at this, the way a computer looks at it, you'll understand that slash 24.
If you look at it as a 32 bit binary number, you'll notice the first 24 digits are all one.
And then the last eight are all zero.
So if you do slash 24, that means your first 24 straight numbers are all going to be one.
And you can't subnet it where you have like 1, 1, 0, 1.
It has to be one straight from the beginning to zero straight at the end.
Or it's not a proper subnet.
And I have no idea what your computer will do with it.
This basically, and I might need, yeah, there we go.
Okay, I got something in the next slide now to demonstrate this better.
But when you look at the IP address and the subnet mask together,
it's easy to determine what IP addresses you can communicate.
Basically, what IP addresses are local and which ones are remote?
This 192.168.1.1 slash 24.
It can contact all addresses between .0 and .255.
Because the bit mask has hidden the 192.168.1 part.
We'll see that right here.
If you look at the two numbers together, the top one is the IP address.
The bottom one is the subnet mask.
And everywhere in the subnet mask that you see a one,
all those numbers in the IP address are effectively masked.
In other words, the computer doesn't look at those as local addresses.
So the 192, the 168, and the one are ignored in this example
because they're masked out by the subnet.
And the only one that's important is the final .1 on the end.
So when you look at it this way, you can see,
you know, if you total up all the possible binary combinations
for those last eight binary numbers,
you got 256 combinations from 0 to 255.
If we added another bit to the subnet mask or subtracted another bit,
it affects which machines are considered local by the computer.
If a frame is not considered local, basically if the frame is not in this subnet here,
if it's not in this 192.168.1 subnet,
then the computer or the node knows it has to use a gateway
to reach the final destination.
It has to use a router essentially.
We got some other network layer protocols as I see MP,
which kind of straddles the network layer and the transport layer.
It's used for trace routes, pings, time to live expired,
junk like that.
There's also R, which resolves IP addresses to MAC addresses.
We're not going to spend a whole lot of time on that here.
If you want to actually learn more about how that works,
you'll have to check the slide in the beginning.
How much time do I got here?
Oh, I'm good.
Well, I knew I was good.
I just got plenty of time.
The transport layer, here we go.
This is probably what you've probably heard the most about.
And in some ways, it's the least interesting, at least to me.
This is where you have TCP and UDP.
You may have heard three-way handshake, four-way handshake,
all that good junk.
But this is the first and only layer that can optionally,
that's important.
It can optionally guarantee the data was delivered and intact.
It can't always, well, you can disable that guarantee.
Basically, TCP can guarantee that your data got where it got to.
UDP is the brain-dead cousin of TCP and can.
It just says, duh, let me send data.
TCP sends data, looks for responses.
And, you know, basically, go ahead.
You need to be a bit of a broadcaster of those things.
And we just need to be a bit of a broadcaster of those things.
Yeah, anytime that you don't really care so much about data delivery,
it's not a big deal if you're streaming a video or streaming some audio.
If, you know, a couple split seconds are lost,
TCP adds so much additional overhead that in that situation,
you would probably actually lose more doing TCP,
at least in a streaming way, than you will with UDP.
Also, VPNs, and some of you, I'm sure,
have probably looked at using the secure shell or something for a VPN.
Any VPN that uses TCP is by definition stupid.
You should use UDP for a VPN.
And I'll get into, well, I'll go ahead and say the reason why.
If you have TCP and it's doing all these additional checks to guarantee data delivery,
and it's encapsulated inside of VPN that's doing all these additional checks to guarantee delivery,
there's no point in doing that twice.
If you're not worried about, you know, your data getting delivered,
just use UDP, and if it's encapsulated in UDP, you don't care.
If you are worried about it getting delivered, do it in TCP,
and if it's encapsulated in UDP, you still have that checking.
So you're not adding all this additional packet overhead.
So it's just better to use something like OpenVPN,
which is UDP by default, although you can't do it with TCP,
but you're brain dead if you do.
So the UDP is smaller packets?
Yes, actually, not just smaller packets,
but as you will see, there's a lot of special frames with TCP that add to overhead,
plus TCP does some hackery to determine if we're transmitting data too fast,
and if we are, it backs off, UDP just sends it out as quick as it can.
So there's no need to do that check twice,
and if we get to a point where we're sending data too fast,
and we have TCP encapsulated in TCP, it slows down twice at an exponential rate.
So you get much less throughput with the TCP VPN.
OK, now I've got an off track.
Either TCP or UDP, they add some information to the frame
so that it can actually be delivered to the proper application.
You know, the application might be Firefox, it might be DHCPD.
It might be, you know, a clause mail, or it could be,
I don't know, Apache, or the XML, anything.
But without that additional data, there's no way for the receiving computer
to know what application to give the data to.
It's responsible for handing off data between applications and the network,
basically, at last point, it's kind of dry.
In order to guarantee delivery, transport control protocol, TCP,
it uses some pretty nice hickory.
It has a lot of, well, really mainly two handshakes that guarantee
that you're able to communicate with whatever machine you're trying to talk to
and for actually shutting that communication down.
Also, there's things called ActPacket,
so those are acknowledgments, ACK,
and every frame has to have an acknowledgment and ActPacket.
So if I send some data to, I don't know, Barnow.Lyzel.net,
my home firewall, with TCP, I will know it got that
when I get the acknowledgment packet back.
If I don't get that acknowledgment packet back, there's one of two things that can have happened.
Either Barnow, the computer I'm trying to talk to,
never got my original packet in the first place, in which case I need to rescind it,
or two, it got it and sent the acknowledgment,
but I never got the acknowledgment, so I have no way of knowing which of those two happen.
So I'll just rescind the packet anyway.
That way I can guarantee that the packet eventually gets through once I get that acknowledgment.
Up till now we've had no way of knowing whether the receiving computer ever actually got what we sent to them.
Now we do because we have these acknowledgment packets,
and this is where you also have, if you talk about TCP VPNs,
you're going to get an acknowledgment packet for whatever you're encrypting,
and an acknowledgment packet for the encrypted connection.
So it's twice the amount of data, data, data, blah.
Apparently I did have too much beer.
It's twice the amount of data you would have to send across the network,
and it's just tangling things up without adding more information.
There's four types of frames we're going to look at here,
but there's not just four types.
There's explicit congestion notifications and some additional types,
but we're mainly just going to look at four,
SIN, AC, FIN, and RST.
To start with, we'll look at the three-way handshake.
This is what's used to initiate a connection,
and it's where we'll first see the SIN packet,
and you shouldn't ever see it outside of a three-way handshake.
Let's say I want to talk to Google.com,
I'll port a Haiti on a TCP connection.
I want to do a web search.
Firefox starts up and immediately sends a SIN packet to Google.
Google.com.
Once Google receives that package,
that's the receiving node there.
It sends back a SIN AC packet,
in other words, both the SIN and the acknowledgment packet
SIN stands for Synchronize.
Both the synchronizing acknowledgment fields are checked, essentially.
They're one.
Once we get that,
we send back an acknowledgment to Google,
saying, hey, we got it.
Not only do we know that Google is receiving from us,
but Google knows that we're receiving from it.
At this point, we can start actually transmitting data.
That first acknowledgment,
it's sometimes called a SIN IC IC,
if you ever hear that or a SIN double IC.
That's what they're talking about.
There's a full-way handshake as well,
for closing down a connection.
Basically, the FIN packet for finish,
it works sort of like the SIN.
If I'm wanting to close down from Google,
I'll send them a FIN packet.
They'll reply with a FIN IC.
At this point, the connection is what's called half open or half closed.
If you're, you know, the glass is half full or half empty kind of guy.
Once you send a FIN packet,
you say, hey, I'm not sending any more data to you.
I'm done sending data,
but you can still send data back to me.
Like, say, I'm doing a W get on some huge, you know,
I don't know touring or DVD or something.
I may send a SIN IC and say, just give me,
I don't know, southeastlinicsfest.tar.gz,
all the videos from here.
And then I'll send a FIN-ish,
because I don't want anything else.
But for the next hour, hour and a half,
the other machine will continue to send me the data that I requested,
and then we'll close it out with its own FIN-ish packet.
There's also the RST packet,
which is basically like the silver bullet.
It says, kill the connection right now.
Once you get an RST, everything shuts down.
So you can see at this point,
Node 2, we'll call that Google.
Google, they've finished sending us,
or Clemson, or whoever has finished sending us all these videos.
They finally send us a FIN packet.
We send them back a FIN IC, and we're done.
Both nodes will fully terminate the TCP connection.
During the period when one site has sent a FIN,
and it's receiving packets,
does it continue to send access to those packets?
Yes, absolutely.
It always continues to send acknowledgments.
It just basically says,
I'm not going to request any more data.
I'm not going to send you any more data,
but it will still send acknowledgments.
Data frames, this is, you know,
we're actually talking about the data we're receiving
as far as these videos.
They don't have any particular special flags.
They're just bulk data essentially with a port number,
and a sequence number, and some other stuff.
I wish I had space on all these slides
to show the actual things,
but we'll see a little bit more
in some of these later ones, I do believe.
Anyhow, every time you get a data frame,
even if the session is half closed,
like you said,
you have to send an acknowledgment,
so the sender knows,
hey, we're getting data.
They're receiving it.
Again, this is only with TCP.
With UDP, they just say,
do I see me got it.
If you don't ever see that act frame,
that acknowledgment, they'll rescind the data.
I mentioned once more of the ports
and the part of our ports,
over like about my area of ports.
Ports of layer five.
I'm sorry, four.
Physical data, network, yeah, four.
Transport layer.
And ports.
And then you said also,
PCF either is program specific
addressing to the programs?
That's basically your port.
And we'll show you right here.
That's what the port is for essentially.
The kernel will create a socket
for that port and send the data
through its filters just to get the data out
and then sends it to whatever application
opened that port.
But that's how TCP can communicate
with the application layer.
And I actually wanted the data,
like in my example, WGet or Firefox
or a send mail or a clause mail
or whatever.
Every TCP frame,
it's got a source port and a destination port.
So if I start up Firefox
and I don't know,
do a Google search,
it will set a destination port of port 80.
That's the worldwide web port,
HTTP port.
You got a question, mister?
No trouble, no trouble.
I ain't real picky.
And it'll set a source port.
That's whatever.
It's some random high number port,
like O32,568.
That Firefox just chose
or the kernel assigned to Firefox
to use randomly as its source port.
And when it gets any sort of data back from that,
it knows what application to send it to.
That's basically it.
They tell it or see if you know
where to send the data portion of the frame.
UDP, here we go.
We get to pick on, you know,
my brain dead NSS cousin.
It's the brain dead cousin of UDP.
It has ports.
And that's about it.
It doesn't do any sort of handshakes.
It doesn't do any sort of acknowledgements.
It just sends data as fast as it can.
Which is good bit faster than TCP in some cases.
In some cases, it's slower
because the transmission media is just unreliable
and you never really ever get everything you wanted.
You wouldn't want to use UDP for downloading
our video stuff here.
Because when you start to get some network congestion,
it's just going to get worse and worse and worse.
And eventually time out and you've only got half the video.
TCP is smart enough to slow down
and speed up when it needs to.
And I don't really have time to go through that whole algorithm
as how it does that.
But basically UDP,
real good for voice over IP,
streaming media, VPNs,
anything where you don't need to guarantee
that data was reliably sent for whatever reason.
Uses the same port numbers,
even though these are actually different ports,
and basically the same way as TCP,
it just knows what socket or what application
to hand the data off to by those port numbers.
Is there sequencing information in these things
that the point gets there ahead of time?
In UDP,
yes, there is a sync with Snubber.
I'm almost positive.
I have to double check.
In TCP there is.
So that if you get packets out of order,
it can put them back in order.
And actually every acknowledgement
has that same sequence number.
In TCP every acknowledgement packet
has that same sequence number.
So the sending computer knows which ones
actually were received and which ones weren't.
And he can intelligently
rescind the one that got missed delivered,
and it'll show up later and they can reassemble.
So we should see a few later.
We'll see some of the actual sequence numbers,
acknowledgement numbers, all that stuff here in just a moment.
When we actually handcraft our very own frame.
The application layer, this is real boring.
It's basically the HTTP DNS Firefox HTTP.
It's just whatever actually makes the payload for the frame.
And since we're not interested in what that actual data is,
we're not really interested in the application layer.
We want to know how to route, how to send,
that sort of stuff.
So it's kind of boring.
But you'll sometimes see,
like Firefox will request a port number to send to you.
Like in this case, you'll see lizilla.net calling 8080.
It's saying instead of normally sending to 80,
I can send to 8080 or 443 or whatever.
It's not hard coded by the application.
The application can actually check and ask,
the kernel to go ahead and craft this packet
to connect to a different port than usual.
All right.
If everybody's still with me,
we're going to go through the fun process
of making our very own baby packet.
And we'll see just how fast she goes up.
We're going to start here with the application layer.
And you can see right down here at the bottom,
I've cut everything off at 32 bits.
You start with zero and go all the way out to one there at the end.
That's actually 31.
So each one of these little diagrams you see in the next few slides
will be actually 32 bits in length.
And you'll see where everything actually is in the real packet.
So if for some ungodly reason,
you develop the ability to read binary ones
and zeroes on the wire,
you'll be able to figure out where everything actually is
without using TCP.
Basically, our application layer will call it send mail
or Firefox, whatever.
It sets the payload.
And here I've just said the payload's 32 bits.
It's real uninteresting.
Maybe it's the number 4.
But, you know, we don't really care what the payload is.
We don't need values for it.
So we're just going to go on and start wrapping the packet up.
As we go down each layer in the stack to the transport layer,
to the network layer, to the data link layer,
we're going to add things to this payload
to get it on down to its next destination.
And the first thing we'll do is we'll add the port numbers,
sequence numbers, flags, yada yada,
that TCP adds.
So you can see the first 16,
the first 16 binary places are reserved for the source port,
which is why ports can only go up to 65,575,
to the 16th power.
And then the next 16th or destination port,
same basic deal.
And then you got the sequence number and acknowledgement number.
Personally, I have no idea why they have both of these
in the same packet.
I would think you could use just one 32-bit number here,
and whether the flag says it's an act or not,
you know, decide whether it's a sequence or an acknowledgement number.
But, apparently, the guys that, you know,
created TCP thought differently.
So we have a few other flags here.
DMRS, we're not going to worry about all that stuff.
Flags, that's where we actually set,
whether it's a sin packet, a sin packet,
an acknowledgement, a reset, a RST,
all that stuff.
They're actually binary ones or zeroes.
So you have a sin zero or sin one,
and acknowledgement zero or acknowledgement one,
and based on whether it's a one or zero,
tells the receiving node,
is this an acknowledgement packet?
Is this a finished packet?
There's a synchronization packet.
That's where all those are coming in.
And when you actually do filtering, you know,
in that filter or, you know,
if you're leading enough to use OpenBSDPF,
you know, when you start checking flags,
that's what you're actually looking for.
It's saying, is this be it one or is it zero?
If you say, you know, I don't want sin packets
from anything else, or I don't want anything but sin packets
unless they're already established,
you say, well, if sin eight one,
don't accept it unless it's already established.
That's where all that logic comes in.
And it just looks at that one bit
and is able to make an intelligent decision.
The window, it's not really that important.
It's sort of like a sizing thing.
I can't really explain it all.
Check some.
Basically sort of like MD5 check some.
It just says, hey, here's a little check some.
If some bits are flipped, this might catch it.
An urgent pointer we're not really going to go into.
It's sometimes used with explicit congestion notification.
Not really all that important.
And then you can see payload down here.
I've actually done the little curly braces.
So you can see this is actually from the last time we did.
Once we've added all this binary information,
we then step down to the network layer.
And the first thing we'll see down here at the very bottom,
I just did the TCP header and payload,
because I couldn't fit everything on one side.
And you know, the text file online,
you'll be able to look at it all and read it all in binary
and hex decimal form,
and really get an idea of where you're, you know, where you're at.
This has got a buttload of flags on it.
You've got version header length, type, total length,
identification number, some flags, fragmentation offset,
time to live, protocol header check, source IP destination,
IP address, and then your TCP header and your payload.
Whole bunch of junk in the network protocol.
The most important things are the source IP address
and the destination IP address.
If you'll notice, there's no subnetting information
in the packet, no subnetting information whatsoever.
Often we don't even know what the subnet is
for the destination IP address,
and what it is for our source IP doesn't matter for the router.
Basically, when we send a,
we'll show you that in the next thing.
Version, if we're talking about IPv4,
it's going to be four minutes.
I mean, four, if we're talking about IPv6, it's six.
You know, you get the idea,
and we're down to two minutes,
so I'm going to, you know, go fast.
Don't ask questions.
Once we get down here,
we have destination MAC address, and source MAC address.
You can see there are 48 bit numbers,
that's why they take up one and a half on each one,
and then you got to check something as well.
If we look right here, the most important thing for you to understand,
based on the destination IP address,
we said our destination MAC address.
It might not be the MAC address for our eventual destination.
It'll often be the MAC address for the next hop,
our gateway, and the next gateway after that.
Wow.
We did get through it.
But basically, what we have,
like, say my local, my computer on my local network connection,
and if I run along this route,
if I want to send a packet to Google,
yeah, 30 seconds, I am going to run along.
If I want to send a packet to Google,
I don't know what Google's MAC address is.
And even if I did, it wouldn't help me
because the MAC address isn't routable.
So what I do, I know Google isn't on my local network.
I know my default gateway is,
so I set the destination MAC address to match my default gateway.
Once it gets that packet,
it strips off this data link layer,
and says, well, I don't know where to get to Google,
but I know somebody who does.
So it sets the destination MAC address
to be the next hop closer to Google.
And then it gets it and does the same thing
until it eventually gets to Google.
That's how they go one hop at a time.
And you'll notice that you never actually see
into the IP address.
You always are sending to the MAC address.
And yeah, you can stop me now.
I'm pretty sure my 30 seconds are up.
Any other questions?
Or you want to holler at anybody?
You can always catch me afterwards.
I'm not hard to spot.
Bring beer and red man,
and I'll talk to you all day.
This work was recorded by View Digital Media,
and is licensed under a Creative Commons Attribution,
share it like version 3.0.
For more information about the southeast,
visit southeast.com.
Visit southeast.com.
So head on over to
O.J.E.C.
All of us here.