hpr-knowledge-base/hpr_transcripts/hpr0515.txt

Episode: 515
Title: HPR0515: Network Basics Part 6
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr0515/hpr0515.mp3
Transcribed: 2025-10-07 22:16:16

---

Hi everyone, this is class 2.
Here I am hiding out in the server room at work, so you hear a whole bunch of noise in
the background.
That would be why.
I have found that if I leave the office and go into the server room thing, I'm going to
go check the avalanche box.
I can pretty much disappear for like an hour and no one asks any questions.
I don't really know where the avalanche box is or how to check it or why it needs checking,
but it certainly does seem to work.
So here I am, chilling out, not doing any work, but recording an HPR episode.
So this is episode 6 in my series of networking basics, and in this episode and this installment
we're going to cover ARP, ARP, and also more or less reverse ARP, although actually DHDP.
So let's start with ARP.
So ARP is the address resolution protocol for your network, meaning that at some point
you've got your little local area network, right, hanging out, mining its own business,
then an incoming packet comes in to the gateway.
And it wants to go to a particular host machine within your local area network.
So in order to find that host machine, the gateway needs to use ARP, the address resolution
protocol, to find out which MAC address matches the IP address that the packet believes
it is trying to get to.
So the ARP program looks in a little ARP cache or an ARP table.
And if it finds the address, the IP address, then the packet can obviously be converted
to the correct packet length if it's not already and put into the correct format and stuff
like that, and it gets sent out to the destination.
If it doesn't find a matching IP address, ARP actually is smart enough to broadcast a
request packet out to the local area network, and it asks if anyone knows who's got the IP
address, whatever IP address that is looking for.
So your device on the LAN, if it's got that IP address, then it will respond.
So yeah, I've got that IP address, my MAC address is this, and so ARP updates the cache,
and then it sends the packet to the destination.
So either way, kind of results in this incoming packet, getting to the correct actual physical
device on the network.
So if you recall from previous episodes, all of that kind of stuff, figuring out MAC addresses
versus IP addresses and things like that, and dealing with the physical machines on the
network, that all happens in the data link layer.
So this would be a layer 2 protocol in the TCP IP structure.
So that is what ARP does.
That is, I guess, as simple as that.
There are a lot of kind of well-known exploits, I guess, not that I know of any of myself,
but certainly hear a lot about it.
For instance, ARP poisoning and things like that, wherein you can almost see the potential
for it.
The gateway sends out a request asking, okay, who's got this IP address, and someone
else's computer says, yeah, yeah, that's me.
I've got that IP address, my MAC address is this, and it gets all the information that
is destined to your physical device, the real physical device, and then typically, it
basically forwards that on to the physical device.
So it all appears quite normal to your computer end of the gateway, because the gateway is passing
the packet, and your device is getting the packet, it just happens to be extra stop along
the way there in the middle, and that would be a man in the middle attack.
And no, I don't know how to do that.
So that is, I guess, a potential for exploitation on the network.
So just kind of be aware of that, I guess.
The reverse of ARP, wherein the gateway is pulling local area network, saying, okay, which
MAC address has this IP address, the reverse of that would be, would have been something
called the reverse address resolution protocol.
And that is, I guess it was being used for a little while, and that, I guess, got supplanted
by BootP, that is B-O-O-T-P, that in turn got replaced by DHCP, so DHCP, oh, and by the
way, all that, all the ARP dust, you can read more about it, and RFC826, DHCP we're covering
is RFC2131, and DHCP is a big one.
It's a pretty complex RFC, you might want to look through it, it's really fascinating,
it's got pretty ASCII pictures, little diagrams and flow charts and stuff, and I probably
couldn't ever hope to cover everything in that document here, because it really is quite
complex and has lots of different potential scenarios that it can deal with, but there
are certain parts of it that, once you get the theory of it down, the other potential scenarios
all kind of fall into place and make a lot of sense.
So DHCP is sort of the ultimate result of RARP and BootP, and in fact, the DHCP is,
I guess you'd say, it was backwards compatible with BootP, and they did that very intentionally,
because they didn't want to break all the BootP networks out there, you know, they wanted
it to be something that can talk to existing network structures that were around at the
time.
I don't have a date on when this RFC was written, the 2131, but I know that it was, I believe
it in turn modified like two previous RFCs, so it was kind of, it strikes me that it
was probably kind of in the making for a little while.
DHCP itself consists more or less of two components.
It's got a protocol for delivering host specific configuration parameters from the DHCP server,
and it's got a mechanism for allocating network addresses to hosts.
So those are the two parts of DHCP that you kind of have to think about, and that'll
make more sense once we get into how everything works when you do DHCP.
And before you bother either reading the RFC or possibly listening to this episode any
further, you might want to fire up your Linux box, or any box really, but I don't know
how to do anything with DHCP on Windows or Mac, but a little bit on Mac, but just do
it with Linux anyway.
So if you fire up your Linux box and drop down to a terminal and bypass your network
manager, like if you're using Genome Network Manager or Wicked or whatever, just kind of forget
that exists for a moment and go into the terminal, probably you'll have to become root because
you're kind of talking to your wireless card and normal users aren't usually allowed
to do that all that well, but if you do, if config, you can see a whole bunch of the different
parameters that are very, very involved when you do get an IP address from a router via
DHCP.
And if you take it even further and actually assign yourself to a network and stuff like
that, and then issue either DHClient, that is DHClient or DHCPCD, kind of depends on
what your distribution uses and what you want to use, but both of those two commands will
give you a little bit of feedback about what's happening.
And I think it's DHClient, really kind of shows you certain signals that are being sent
and received and things like that, and sometimes seeing it fail is just as informative as seeing
as connected to your network, so you can play around with that and just kind of see what
happens.
DHCP itself supports three different mechanisms for giving out IP addresses, and I, okay,
so I guess before I go further, I should say, so DHCP in case you don't know is that
which hands out IP addresses, and that's quite scalable.
DHCP, you see being implemented on your little local area network at your apartment, and
you see it at your big ISP when it's giving out IP addresses throughout your neighborhood.
It's something that happens on lots of different levels.
When you're trying to get an IP address so that you can join a network and kind of interact
with that network, you are using DHCP, you are interacting with DHCP, whether you know
it or not.
So DHCP supports three mechanisms for IP address allocation.
There's automatic allocation in which DHCP assigns a permanent IP address to a client.
I don't really, I don't see that so much these days, but I'm sure it's implemented somewhere,
but just speaking from my apartment, that's not really something I see.
A dynamic allocation is when the DHCP assigns the IP address to a client for a limited
period of time until the client says, okay, I'm finished with it, you can have that IP
address back.
That's more or less the default behavior of, for instance, your home router.
It's just whenever you open up your computer and ask to get onto the network or more frequently
your wireless interface or your wireless, your network manager asks, hey, I want to get
on this network.
Usually quite often invisible to us because it's just automatic now, but whenever that happens,
it hands out the next available IP address.
It doesn't care whether you're on your computer, your desktop, your laptop, your Nokia, your
cell phone, your gaming console, it just doesn't matter.
That's the default behavior of most routers that you and I are going to be using on an
everyday basis.
And then there's also manual allocation in which a client's IP address is assigned to it
by the network administrator and DHCP is used just to convey the assigned address to
the client.
And that you see in a lot of businesses where they've kind of hard-coded all the IP addresses
to different work stations and stuff like that.
Particularly network will use one or more of any of these three mechanisms and you may
do that at your own house.
Who knows?
I mean, I certainly have a lot of my devices I've defined their IP address because I want
to be able to SSH over to my Slackware laptop from my Fedora Triple EPC without having
to type, you know, well, without particularly having to go over to the Slackware laptop
which kind of defeats the purpose and do an if-config and see exactly what my IP address
is.
So I manually assign it so that any time that MAC address pops open, you know, I open
up the laptop, that MAC address comes to life and pulls the network for an IP address.
It's going to get the same IP address all the time.
But then again, of course, you want friends to come over and be able to get onto the network
and you don't exactly have their MAC address.
So you probably have a few numbers in your network available for extra people who you
have not manually assigned an IP address and that's going to be the dynamic allocation
of those things.
But that's not uncommon to be using more than one of those different mechanisms.
Okay.
So a typical client server interaction, well, first, like I say, you open up your laptop
or you turn on your desktop or whatever.
So your client starts to broadcast, well, if you want to break it down more specifically,
you open up your computer and you actually find your wireless card to a network and then
you issue the command DHCPCD or DHClient, whatever.
And now your computer becomes the client and it broadcasts a DHCP Discover message on
its local physical subnet.
The DHCP Discover message will include options or might include options that kind of suggest
a certain value for a network address and a list duration.
I know that DHClient does this.
DHClient has a little configuration file or a log file, I think in maybe slash temp or
it might be, yeah, I think it's slash temp.
I forget really, but it will keep track of its last known IP address.
So if I crack open my triple EPC and yesterday it was 192.168.1.4, then today when I ask
for a DHCP or when I send out a DHCP Discover message to the server, to the DHCP server,
my computer is kind of suggesting, hey, why don't you just, if it's available, why don't
you give me 192.168.1.4.
That's not a necessary, you know, that it might not include suggested values, but it might.
It just depends on the situation and what you're using to request that IP address.
Now each server, I mean, if you're in a large-ish network, you know, you might have more
than one DHCP server in the area.
So each server is going to get this DHCP Discover message and each one will be able to respond
with a DHCP offer message.
That includes the available network address, specifically in the YIADDR, so sort of YIADDR
field, which will go through in a minute, but there's a very specific, obviously, place
for where it stores the available IP address that they're going to offer.
The client will then receive one or more DHCP offer messages from one or more servers,
and it can choose which server it wants to kind of latch onto.
Again, in your typical home network, this isn't going to really be an issue if it's just
a one-router kind of deal, but it could be in a larger network where you're actually
getting responses from more than one DHCP server, and the client is going to then broadcast
a DHCP request message that obviously must define which server it is chosen to use,
and the DHCP request message is relayed through all the DHCP and BootP relay agents.
So anything on the network that is programmed to pass on DHCP or BootP messages are getting
this DHCP request message.
The servers that receive the DHCP request message will, if they're not the server that
is being chosen, they take this to mean to stop broadcasting, to forget about the request.
They kind of go away, they turn themselves off, they're not going to.
They receive it, I guess, as a DHCP denial.
The server that does get the message is receiving a DHCP act, ACK.
Now there's no DHCP denial message from the client.
If you've got two servers in there and they receive the DHCP request, one of them obviously
is going to, well, both of them will respond, yes, I've got an IP address for you.
All that the client needs to send back is a yes, I choose server foo, and then server
foo gets that as a positive response.
Server bar gets that as basically a negative response, because it sees that client has chosen
to server foo.
We'll forget about the whole interaction and go back to sitting around doing whatever
servers do.
It's not as if though the client has to send two different messages like yes to server
foo and notice server bar, it just sends one message to both servers, so it's nice and
efficient that way, and obviously that can be done to as many servers as you want.
There's only one that's being chosen and anyone else who doesn't get the little response
back that yes, I'm choosing you, give me your IP address, the transaction ends there
for them.
So the server that does get the DHCP request back and it's a positive response sends back
a DHCP act message, and that is ACK, so it's like acknowledgements, like DHCP acknowledgement.
So it sends that back to the client, so the client gets the DHCP act message with various
configuration parameters, and the client performs a final check on all of those parameters,
meaning that it needs to check to make sure that it can actually use that IP address, because
you don't really know, especially on a big network, I mean how many people are requesting
for an IP address at that very moment, and is that IP address trying to be applied to
two different machines at the same time, and if so that could be a problem.
So if the client detects that the IP address did get assigned out from under it, and it
actually does this through the use of ARP, the address resolution protocol that we just
talked about earlier, then the client sends a DHCP decline message to the server, and it
kind of starts over it, it says, okay, I better do another DHCP request.
I have actually witnessed this once, I was in a hotel, I think it was a hyalinic
test, and it was not this past year, but the year before, in the Durham hotel, or whatever
that one is called, and I was sitting around, and I wanted to sign on, and I was using,
I think, Debbie and on my triple EPC at the time, and I did a DH client, and it sent everything,
and it was kind of like, it's a fairly verbose command DH client, it gives you a lot of
feedback, and it went through the whole process, and it looked like I was going to get the
IP address, and I was about to go online, and then it started over again, it pulled again,
it did the DHCP request again, so that was kind of interesting to see.
I think it might be kind of not rare, but it is something that you kind of have to look
for, because you have to be in a busy area where people are grabbing IP addresses left
and right, and everyone is kind of scrambling for it, which is what happened in that case.
But assuming that the IP address is not snatched away from the client, then the IP address
is assigned to the client, and the client is now online, or it has an IP address.
In the case that the client ever should receive something called DHCP in 8K, then that means
that the server no longer has an IP address to send the client, probably for the same reason,
when the server first got the request, it thought it did have an IP address, and then by the time
the client has sent out the DHCP request saying, okay, give me that IP address, the IP address
has been assigned to something else, and so the server has to respond with the DHCP in 8K,
and then again, it is a fairly graceful interior, it is a fairly graceful process,
the client simply restarts the little configuration process, not like anything really bad happens.
That is the process of DHCP, the final stage of DHCP, I guess, in terms of the server client
relationship, would be in the case that the client decides that it no longer needs an IP address,
so if I send a shutdown signal to my computer, then it is going to send a DHCP release message
to the server. Note that this is a graceful shutdown, if you just pull the plug on your desktop
or something, or your laptop battery suddenly dies and doesn't do so gracefully, just shuts
your power off or something, then it is probably not going to have a chance to send that signal,
but in certainly in the case of actually shutting down, then it will send that DHCP release
message to the server, server receives that, and it will make that IP address now open again,
and again, the way that they identify the lease and everything is this client identifier,
or the CHADDR field, that would be DHCP release stuff. So to review that, some of the key terms
there, it would be DHCP discover, and again, you can look for a lot of these terms in DH
client or DHCP CD, and also if config, and IW config, and things like that, all the output from
those commands will, you'll kind of hit on some of these terms, but the DHCP discover is the
client broadcast to locate an available server. The DHCP offer is a server response to the DHCP
discover broadcast, saying that yes, I've got an IP address for you. The DHCP request is then the
client sending sort of a confirmation to the server, saying yes, I hear you, and yes, I do want
that IP address that you are telling me is available. DHCP Act is again the server talking to the
client, saying okay, here's the IP address, and here are some configuration parameters. DHCP
in AK will be a server to client message, saying actually I lied, I don't have an IP address available,
you better try that again. DHCP decline will be a client message, saying that we're detecting
via ARP, that that IP address is actually already in use, and we can't grab it. DHCP release
would be the client telling the server that we're finished with the IP address, so you can reallocate
it whenever you want to. Okay, so here's the format of a, of a DHCP message. The first field,
which is one octet is called the op field, OP, that is message op code, and message type,
one is going to be the boot request, and two is going to be the boot reply. Second field is
H type, and that is one other octet, and that's the hardware address type, and that's actually
something that kind of gets inherited from the whole ARP thing, and it just sets the hardware
address type, which would be something like 10 megabit ethernet, something like that. The next
field is H-LEN, which is H-L-N, which is hardware address length, and there are different
codes for that, and that's one octet, and then the next field is hops, which is one octet long,
and that is, well the client is going to set that to zero, but it could also be used by relay agents.
XID is four octets long, and it is the transaction ID, which is basically just a random number chosen
by the client, and it is used by the client and the server both to associate messages and
responses between the two. So, when this whole interplay of DHCP request and offer and stuff
is going about, in order to kind of identify that we're still carrying on the same conversation,
we set our XID field to something random, but consistent, so that we know that it's still
the same conversation. The next field is two octets long, and it is seconds elapsed, well SECS,
what the field is called, but it is seconds elapsed since the client began this whole DHCP thing,
so from the moment that DHCP, rather than the client, sends out that DHCP request,
this seconds field starts to get filled in. The next field is flags, that's two octets,
there are, as far as I know, and understand there are two flags, there's B for broadcast,
and then there's in BZ, which is must be zero, which just means that that's reserved for future use.
CI ADDR, CI address, basically, that's four octets, and that's the client IP address,
so it is only going to be filled in if the client is actually bound or renewed, or it is in a state
of rebinding that IP address, that is to say that unless that IP address is actually bound to the
client, and the client can respond positively to an R request, that, hey, do you have this IP address,
if those things are true, then this field is set, if those things are not yet true,
then the CI ADDR field is going to be empty, but it doesn't get filled in until the IP address is
actually spoken for. The next field is four octets long, and it is your client IP address,
so your IP address is Y-I-A-D-D-R, that's what that stands for, so that is your IP address.
CI address is another four octets, and that's the IP address of the next server to use as the,
well, it's the server that's being returned in the DHCP offer, or a DHCP act, and then G-I-A-D-D-R
four octets long, that's the relay agent IP address. You might not see that filled in in a lot
of small networks, because you might not be using any relay agents, but then G-I-A-D-D-R,
that's four octets, that's the relay agent IP address, there's the C-H-A-D-D-R, which is 16
octets, and that's the client hardware address, so obviously that's the MAC address of the client,
and then there's S name, which is 64 octets long, and that's the optional server host name,
and then finally, or not finally, almost finally, and ultimately, there's file field, which is 128
octets long, and this can be actually quite a few things, it can actually be the directory,
and the path, if it's a DHCP offer, it can be a generic name, it can be blank, and DHCP discover,
it can be a boot file name, it really depends on what's going on with what kind of message this is,
and then finally, there's an optional field, and well, it's an options field, and it's a variable
length, and it really depends on what kind of correspondence is going on here, in terms of what
you're going to put in the options field, or rather what your computer is going to put in the
options field, so that's the internals of the DHCP message, so that's an overview of DHCP,
and like I said, it can be a very detailed process, I mean, there's a lot of different variables
involved, how many servers are there offering DHCP, IP addresses, how many clients are asking for them,
are you renewing a lease, are you relinquishing it, have you set up a data-chip address,
or a predetermined IP address for yourself, or is this going to be something randomly chosen,
how many addresses are in that subnet, how many addresses are actually available,
and so on and so forth, so the best way I guess to learn about this kind of stuff would be to
play around with routers a lot, either that or build a DHCP server on one of your boxes,
and have that manage that sort of thing for you, so again you can read a lot more about it if
you really want to, RFC 2131, and ARP was again RFC 826, that was networking basics, I should probably
get back to work, talk to you later. Thank you for listening to Hack or Public Radio,
HPR is sponsored by caro.net, so head on over to CARO.NAT for all of those of you.