Jump to content











Photo

Questions about the dhcp protocol

dhcp

  • Please log in to reply
6 replies to this topic

#1 tinoy69

tinoy69

    Member

  • Members
  • 30 posts
  •  
    Philippines

Posted 07 October 2017 - 06:50 AM

I am trying to learn about the dhcp protocol, I've created a program which snoops on dhcp messages (both client and server, so that I may not have to look at wireshark), my questions are

 

1) on the client, parameter option 55 (parameters list), this usually has a long list to tell the server to support each cmd, but looking at other dhcp server implementations, the least the dhcp server usually send is cmd 1,3,6. Now my question is, is there a min cmds to pass back to the client (ignoring other cmds in the parameter list)? Can you please tell me where in the rfc2131 (or other rfc) is this info?

 

2) why is setting the router (option 3) to "0.0.0.0"? what does this mean to the client?

 

3) does the xid field constant for a client? does a server use this to uniquely identify a client or does it use the hardware (mac) chaddr field, which doesn't change between msgs?

 

4) I know that windows doesn't honor hostname (option 12), can it be possible to set the hostname (computername), on the dhcp level on windows? possibly by writing a driver at boottime? are there 3rd party software/driver that can do this?

 

5) is my understanding correct on boot on lan? client request boot filename, request boot file from tftp, then control passes to boot file (pxelinux.0) for sanboot (iscsi, aoe, etc)? is this also applicable for boot on lan uefi boot (via gpt)?



#2 erwan.l

erwan.l

    Gold Member

  • Developer
  • 1997 posts
  • Location:Nantes - France
  •  
    France

Posted 08 October 2017 - 01:43 PM

I am trying to learn about the dhcp protocol, I've created a program which snoops on dhcp messages (both client and server, so that I may not have to look at wireshark), my questions are

 

1) on the client, parameter option 55 (parameters list), this usually has a long list to tell the server to support each cmd, but looking at other dhcp server implementations, the least the dhcp server usually send is cmd 1,3,6. Now my question is, is there a min cmds to pass back to the client (ignoring other cmds in the parameter list)? Can you please tell me where in the rfc2131 (or other rfc) is this info?

 

2) why is setting the router (option 3) to "0.0.0.0"? what does this mean to the client?

 

3) does the xid field constant for a client? does a server use this to uniquely identify a client or does it use the hardware (mac) chaddr field, which doesn't change between msgs?

 

4) I know that windows doesn't honor hostname (option 12), can it be possible to set the hostname (computername), on the dhcp level on windows? possibly by writing a driver at boottime? are there 3rd party software/driver that can do this?

 

5) is my understanding correct on boot on lan? client request boot filename, request boot file from tftp, then control passes to boot file (pxelinux.0) for sanboot (iscsi, aoe, etc)? is this also applicable for boot on lan uefi boot (via gpt)?

 

When it comes to DHCP protocol, many different hardware/software vendors have implemented it their own way.

 

1/ About option 55, you may want to double check the RFC, but my experience is that the client may ask for A and receive B from the server and this without failing.

 

2/ option 3 = 0.0.0.0 basically means no gateway.

Not setting this option probably has the same effect.

Some scenario, like installing windows over iscsi requires this workaround.

 

3/ the xid stands for "transation id" : this is unique to one "discussion" between the client and server - there is no logic i believe on how the number is generated - I myself generate it randomly for each session.

 

4/ hostname - do you mean server side or client side?

server side should be as simple as setting the option.

client side : apart from intercepting the packet and rewriting it OR patch some system file, no clue there...

 

5/ Not sure what the question here.

Still, always remember the DORA principle : discover, offer, request, accept.

IF the client is pxe booting and IF the server offers a boot file then here you go : your client will execute your boot strap.



#3 tinoy69

tinoy69

    Member

  • Members
  • 30 posts
  •  
    Philippines

Posted 08 October 2017 - 02:54 PM

Thank you erwan...

 

clarification on 5)

 

I mean with legacy bios (boot from lan), the client boots from the bootfile given by the server...in uefi mode (also boot on lan), is this process similar? does client gets a bootfile then passes it from there or are there additional steps? what i'm trying to learn is that, is your tiny pxe server able to serve uefi bootstrap and boot client through uefi (via gpt partition), if so, do you have a tutorial on how to do it?

 

i know that there are several iscsi diskless system, that are able to boot gpt partitions (diskless), i want to know how dhcp is serving the bootstrap to boot uefi over lan, as i wrote the program just for this purpose...



#4 erwan.l

erwan.l

    Gold Member

  • Developer
  • 1997 posts
  • Location:Nantes - France
  •  
    France

Posted 08 October 2017 - 03:12 PM

Yes TPS is able to work in both legacy bios and UEFI mode.

See a discussion here.

 

And a video illustrating it.

 

 

About iscsi booting, you can either server a conf file to ipxe instructing to boot iscsi or even simpler, fill in option 17 for ipxe to boot straight to your iscsi target.



#5 tinoy69

tinoy69

    Member

  • Members
  • 30 posts
  •  
    Philippines

Posted 16 October 2017 - 12:17 PM

couple of more questions, btw, thanks erwan for answering them...

 

1) the rfc states that usage of icmp and arp is neccesary, do you use them in your tinypxe server?

 

2) does the order of the dhcp options matter?

 

3) in proxydhcp mode, what do i need not to send? and what rfc do i need to read on the bootp relay agent function?

 

4) also in your last reply, tinypxe managed to boot the ipxe in uefi mode, but have you been able to boot the actual gpt partition from windows after this (also in uefi mode)?

 

in legacy i just image the boot partion (dd for windows) and that works in iscsi, if using uefi mode, can simply imaging the gpt partition and using that in iscsi target, works the same? or do i need more additional steps in preparing gpt partition for iscsi boot in uefi mode?


Edited by tinoy69, 16 October 2017 - 12:25 PM.


#6 erwan.l

erwan.l

    Gold Member

  • Developer
  • 1997 posts
  • Location:Nantes - France
  •  
    France

Posted 21 October 2017 - 11:11 AM

couple of more questions, btw, thanks erwan for answering them...

 

1) the rfc states that usage of icmp and arp is neccesary, do you use them in your tinypxe server?

 

2) does the order of the dhcp options matter?

 

3) in proxydhcp mode, what do i need not to send? and what rfc do i need to read on the bootp relay agent function?

 

4) also in your last reply, tinypxe managed to boot the ipxe in uefi mode, but have you been able to boot the actual gpt partition from windows after this (also in uefi mode)?

 

in legacy i just image the boot partion (dd for windows) and that works in iscsi, if using uefi mode, can simply imaging the gpt partition and using that in iscsi target, works the same? or do i need more additional steps in preparing gpt partition for iscsi boot in uefi mode?

 

1/ Yes, I use icmp/arp to check if an IP is available before proposing it to the dhcp client

 

2/ I would say that option 53 probably needs to be first, but all other options do not matter about the order

 

3/ I myself use proxy dhcp mode mainly to add the boot filename and next-server options - i would say start with rfc2132 but dont quote me there, could be wrong.

Look at the wikipedia to find your RFC's.

 

4/ Never tried to boot windows in gpt/uefi mode using ipxe.

Thus I would be tempted to say that using a MBR partition or GPT partition should not matter in a network boot scenario.

 

Good description below from the fog project.

As one can see, this is a standard D.O.R.A process with one extra step (3) where the Proxy DHCP adds some extra informations (what to download, where to download from).

 

How ProxyDHCP works
  1. When a PXE client boots up, it sends a DHCP Discover broadcast on the network, which includes a list of information the client would like from the DHCP server, and some information identifying itself as a PXE capable device.
  2. A regular DHCP server responds with a DHCP Offer, which contains possible values for network settings requested by the client. Usually a possible IP address, subnet mask, router (gateway) address, dns domain name, etc.
  3. Because the client identified itself as a PXEClient, the proxyDHCP server also responds with a DHCP Offer with additional information, but not IP address info. It leaves the IP address assigning to the regular DHCP server. The proxyDHCP server provides the next-server-name and boot file name values, which is used by the client during the upcoming TFTP transaction.
  4. The PXE Client responds to the DHCP Offer with a DHCP Request, where it officially requests the IP configuration information from the regular DHCP server.
  5. The regular DHCP server responds back with an DHCP Ack (acknowledgement), letting the client know it can use the IP configuration information it requested.
  6. The client now has its IP configuration information, TFTP Server name, and boot file name and it initiate a TFTP transaction to download the boot file.


#7 tinoy69

tinoy69

    Member

  • Members
  • 30 posts
  •  
    Philippines

Posted 22 October 2017 - 02:17 PM

thank you erwan, although it's a little bit confusing to me (the proxy dhcp part), I'll try to research a bit more into it...thank you for the link to the fog project, reading it now...on more thing...

 

i know that when a dhcp server receives a dhcp discover/request msg, does the server, answer until it receives a client reply (i read on the rfc about retransmission), for example, if the server receives discover, does it reply a continuous dhcpoffer command (with varying times in between) until it receives a client dhcp request msg? same for dhcpack?







Also tagged with one or more of these keywords: dhcp

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users