DHCP Discovery

Go To Last Post
16 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Right guys, I'm working on DHCP Server for an embedded device.  I have the following example to work from:

 

DHCP: Discover (xid=21274A1D)
DHCP: Op Code (op) = 1 (0x1)
DHCP: Hardware Type (htype) = 1 (0x1) 10Mb Ethernet
DHCP: Hardware Address Length (hlen) = 6 (0x6)
DHCP: Hops (hops) = 0 (0x0)
DHCP: Transaction ID (xid) = 556223005 (0x21274A1D)
DHCP: Seconds (secs) = 0 (0x0)
DHCP: Flags (flags) = 0 (0x0)
DHCP: 0............... = No Broadcast
DHCP: Client IP Address (ciaddr) = 0.0.0.0
DHCP: Your IP Address (yiaddr) = 0.0.0.0
DHCP: Server IP Address (siaddr) = 0.0.0.0
DHCP: Relay IP Address (giaddr) = 0.0.0.0
DHCP: Client Ethernet Address (chaddr) = 08002B2ED85E
DHCP: Server Host Name (sname) = <Blank>
DHCP: Boot File Name (file) = <Blank>
DHCP: Magic Cookie = [OK]
DHCP: Option Field (options)
DHCP: DHCP Message Type = DHCP Discover
DHCP: Client-identifier = (Type: 1) 08 00 2b 2e d8 5e
DHCP: Host Name = JUMBO-WS
DHCP: Parameter Request List = (Length: 7) 01 0f 03 2c 2e 2f 06
DHCP: End of this option field

 

My question relates to the size of the "Server Host Name" and "Boot File Name".  What size is the field to leave blank?

 

Thanks freaks...

This topic has a solution.
Last Edited: Fri. Nov 9, 2018 - 10:13 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You do know that there are RFCs for all the internet protocols don't you?

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

    One is 128 bytes, the other one 64 bytes, so in total 192. I don't remember which one is which. RFC will tell you exactly. Often you can see 192 bytes of zeros in DHCP messages about which Wikipedia says ir is a legacy from the Boot protocol from Apple which DHCP is based on.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

my eyes must be going, the data I was looking at said 4B I thought it was saying 48

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

On widows, is the DHCP packet encapsulated in a bootp header or is it okay just to encapsulate it in the UDP?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DHCP is essentially an extended for of BOOTP, and uses the same basic UDP ports and header, but in no sense in a DHCP packet "encapsulated" in a BOOTP packet.

 

https://www.cse.wustl.edu/~jain/cis678-97/ftp/f32_dhc.pdf  seems like a good explanation.

 

Edit: URL fixed.

 

Last Edited: Mon. Nov 12, 2018 - 07:07 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

guys I'm having trouble with the header for BOOTP/DHCP.  There are numerous headers out there so I'm having trouble working out the header.  See below for the header I'm working on:

 

struct dhcp_discovery_header{

	unsigned char

		op_code,
		hw_type,
		hw_length,
		hops;

	long trnsaction_id;

	unsigned short

		seconds,
		braodcast_flag;

	unsigned char

		client_ip_addr[4],
		my_ip_addr[4],
		servere_ip_addr[4],
		gateway_ip_addr[4],

		client_hardware_addr[16],
		server_name[64],
		filename[128];

	int majic_cookie;
	int end;
};

Any advise is greatly appreciated? Everything is okay until after the filename field.  This is also where different examples deviate.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ever heard of this thing called "Linux"? I can't help thinking that somewhere in the kernel they might already have defined standard headers for things like BOOTP and DHCP. Maybe try a search at "lxr"? There seems little point in reinventing this particular wheel.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Clawson, I got it.  There should be 64bytes at the end for vendor specific information.

 

Thanks anyway lad.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK well just for reference it is here:

 

https://elixir.bootlin.com/linux...

 

That is:

struct bootp_pkt {		/* BOOTP packet format */
	struct iphdr iph;	/* IP header */
	struct udphdr udph;	/* UDP header */
	u8 op;			/* 1=request, 2=reply */
	u8 htype;		/* HW address type */
	u8 hlen;		/* HW address length */
	u8 hops;		/* Used only by gateways */
	__be32 xid;		/* Transaction ID */
	__be16 secs;		/* Seconds since we started */
	__be16 flags;		/* Just what it says */
	__be32 client_ip;		/* Client's IP address if known */
	__be32 your_ip;		/* Assigned IP address */
	__be32 server_ip;		/* (Next, e.g. NFS) Server's IP address */
	__be32 relay_ip;		/* IP address of BOOTP relay */
	u8 hw_addr[16];		/* Client's HW address */
	u8 serv_name[64];	/* Server host name */
	u8 boot_file[128];	/* Name of boot file */
	u8 exten[312];		/* DHCP options / BOOTP vendor extensions */
};

Once you pass the IP and UDP header that starts to look very similar to your code in #8

 

PS a few years since anyone else called me "lad" cheeky

 

PPS Linux contains every internet protocol you ever dreamt of (and because most of the internet actually runs on Linux machines it's likely the "definitive" version) so I'd always look there for both packet layouts and also perhaps a peek at how the code is really done! (in fact the reason most people don't write internet stacks these days is because if they want to make an "Internet device" they just run Linux on it anyway)

Last Edited: Tue. Nov 13, 2018 - 05:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The vendor field in the information I found was 64 bytes - wireshark likes it so I'll not fix it if its not broken.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Fianawarrior wrote:

There are numerous headers out there so I'm having trouble working out the header.

 

I guess you mean options ? I find protocols using options to be the most awful ones. It takes many CPU resources to handle and they are evolving. For DHCP there are many of them with many of them of variable length (really awful).

 

See these (from Wikipedia):

    Some of the options are meant for both client and server, some only for client, some only for server.

 

    To implement a DHCP server is much more difficult than a client. Expect to receive bad packets from clients, to get corrupted messages, to get options that you do not support etc. You need a strategy for all these unexpected events. Sometimes you ignore an option and reply, sometimes you need to ignore and drop a packet.

 

    See this scary article.

 

    You need to make your mind and write down a list of features you want to implement. You won't be able to implement everything. And even if you would, in a year or two new enhancements are put in place. How are you going to update your devices in the field? Big guys have resources for this and they release periodic updates.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks angelu, that was an interesting post.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Okay just one last question...  I swear to God!  

 

Have a look at the following: 

 

https://www.amazon.co.uk/TL-PA4020PKIT-Passthrough-Powerline-Configuration-Required/dp/B01M16AZTI/ref=sr_1_sc_3?ie=UTF8&qid=1542149449&sr=8-3-spell&keywords=Power+Link+adoptor

 

Do this act just like a wired link?  i.e. there is no protocol shenanigans???

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

    Like a wired or Wifi or any other technology bridge. I doubt they can act like a hub or switch to allow you to connect more than two. Read Wikipedia.