Mac OS X:Analysis of the Use of the Boot Server Discovery Protocol in NetBoot

tbi0h023f5

Analysis of the Use of the Boot Server Discovery Protocol in NetBoot
Introduction
　　NetBootuses the Boot Server Discovery Protocol (BSDP) to communicate networkboot image options between clients and servers. BSDP is implementedwithin the Vendor Options of DHCP as defined in RFC 2132. Options notpresent within the DHCP specification are provided as vendor-specificinformation.
　　Understanding the content of the DHCP and BSDP communication betweenservers and clients can provide excellent insight for troubleshootingthe NetBoot process. In this article I explain the components of atypical DHCP packet, dig deeper into the vendor options andBSDP-specific options, then I describe the NetBoot process from theNetBoot server perspective.
　　The following diagram provides a visual description of the flow oftraffic between a NetBooting client, a DHCP server, and a NetBootserver during the initial phase of the NetBoot process.
　　The first half of this phase is a standard DHCP exchange. Thisarticle will not delve into a DHCP exchange, but it is worthwhile tounderstand the basic anatomy of a DHCP packet.


DHCP Packet -- Basic Components
　　The following is a DHCP ACK[SELECT] packet from a NetBoot server.

IP Header4 = IP version 5 = IHL (Internet Hdr. Length) = 20 bytes 00 = Type of Service 0199 = 409 = packet length a4eb = 42219 = id 0 = Flags 000 = Fragment offset 40 = 64 = ttl 11 = 17 = protocol (17 = UDP) be3e = header checksum 0a00 010b = 10.0.1.11 = packet source 0a00 0120 = 10.0.1.32 = packet target

UDP Header 0043 = 67 = source port 0044 = 68 = target port 0185 = 389 = packet length 7966 = UDP header checksum DHCP payload (RFC 951) 02 = 2 = opcode type (BOOTREPLY) 01 = 1 = hardware address type 06 = 6 = MAC address length 00 = 0 = hops 0000 9214 = 0x9214 = transaction ID 0000 = 0 = seconds since boot time

DHCP payload (RFC 951) 0000 = flags (unused) 0a00 0120 = Client IP Address 0000 0000 = "Your" IP address 0a00 010b = Server IP = 10.0.1.11 0000 0000 = Gateway IP address 0x0034 -- 0x0043 = Client MAC address 0x0044 -- 0x0083 = Server Hostname 0x0084 -- 0x0103 = Boot file DHCP Vendor Extensions (RFC 1048) 6382 5363 = (99,130,83,99) = Magic # 0x0106 -- 0x0*** = Vendor options

Vendor Specific Information Analysis
　　The vendor specific information portion of a DHCP packet begins atoctet # 0x0104. This portion of the packet is defined by specifying theRFC 1048 "Magic Number" -- a sequence of numbers that indicates thatthe following portion of the packet is encoded as a sequence ofcode/length/value fields intended for transmitting vendor-specificinformation between clients and servers. I will take the packet tracefrom the previous page as an example:
　　To read the options in the vendor specific information option, startwith the first octet after the magic number. Using the example above,"35" (hexadecimal) is the option "code", which, according to RFC 2132corresponds to (ASCII 53) "DHCP Message". The length of the data inthis option is "01" octets. The value of this option is containedwithin the next "01" octets which contains "05". This value is definedas the DHCP message "ACK" by RFC 2132.
　　The next code/length/value chunk starts with "36", is 4 octets long,and has the value "0a00010b". 36 corresponds to ASCII 54, whichrepresents the "Server ID" DHCP tag. The value type of that tag is IPnotation, therefore the value translates to "10.0.1.11". The fulltranslation of this packet is described in the following table.
CodeTagValue35 (53)DHCP MessageDHCP DISCOVER36 (54)Server ID10.0.1.113c (60)Vendor ClassAAPLBSDPC11 (17)Root Pathnfs:10.0.1.11:/Volumes/Sto...Restore.dmg2b (43)Vendor Options01010208 ... 74303031　　The Vendor Options value is "opaque". While the format follows thesame code/length/value format as the Vendor Specific Informationoption, the option codes are defined by the vendor rather than an RFC.NetBoot leverages the Vendor Options option for communicating BSDPmessages between the server and the client.
　　Applying the same reading technique to the Vendor Options value, wecan see that the packet contains BSDP options 1, 8, and 130 (0x82). Byexamining the bootpd source code (or simply its debug output), you canascertain the tags for each of these codes so that you can understandthe value of that option.
CodeTagValue01 (1)BSDP Message TypeSELECT08 (8)Selected Boot Image0x8100052a (Image ID: 1322)82 (130)Machine NameNetBoot001　　Other BSDP options that you will see used for NetBoot are listed in the following table.
CodeTag1BSDP Message Type (1: LIST, 2: SELECT, 3: FAILED)2BSDP Version3Server ID4Server Priority5Reply Port7Default Boot Image8Selected Boot Image9Boot Image List (ID [4 octets], Name length [1 octet], Name. [n octets])

NetBoot from bootpd's perspective
　　Deciphering the Vendor Options from a packet trace can be done, butit is far easier to simply allow bootpd to provide the translatedinformation via verbose mode, especially when it comes to decipheringthe BSDP-specific vendor options. To place bootpd into verbose,non-daemon mode, run the following with root privileges on Mac OS 10.4+Server:
　　launchctl stop com.apple.bootpd
launchctl unload /System/Library/LaunchDaemons/bootps.plist
/usr/libexec/bootpd -dv
　　To discontinue verbose mode and restore standard NetBoot server functionality:
　　Control+C to terminate bootpd
launchctl load /System/Library/LaunchDaemons/bootps.plist
launchctl start com.apple.bootpd
　　When you first start bootpd, it will display basic information suchas which network interfaces it is monitoring and routing information:
bootpd[27240]: server starting
bootpd[27240]: interface en0: ip 10.0.1.11 mask 255.255.0.0
default: 10.0.1.1
10.0 ==> link 4
127 ==> link 0
169.254 ==> link 4
　　Notice the lines that start with "bootpd" -- these lines are whatyou would normally see in the system.log file. The number in bracketsis the process id of bootpd.
　　If you open the Startup Disk Preference Pane on a client machine, orNetBoot a client, then bootpd will activate. Upon activation, bootpdinitializes any DHCP subnets based on information kept in NetInfo. Italso reads any NetBoot configuration information kept in NetInfo. Seethe bootpd man page for more details on configuration information keptin NetInfo.
bootpd[27240]: opening hierarchy starting at .
bootpd[27240]: opened domain 127.0.0.1/local
bootpd[27240]: server name pixel.roscoe.bombich.com
roscoe.bombich.com
DNS 10.0.1.1
bootpd[27240]: subnets init using domain . failed:
/var/db/dhcpd_leases: No such file or directory
bootpd[27240]: bsdpd: re-reading configuration
bootpd[27240]: bsdpd: shadow file size will be set to 48 megabytes
bootpd[27240]: bsdpd: age time 00:15:00
　　After reading the NetInfo settings, bootpd warns that initializingsubnets failed and that /var/db/dhcpd_leases does not exist. This isexpected because, in this case, the NetBoot server is only providingthe NetBoot service, not the DHCP service.
　　Upon initialization, bootpd will also search the configured NetBootsharepoints for valid NetBoot sets. In verbose mode, each set is listedalong with the sharepoint that it resides upon, its name, Identifier,Type, BootFile, Disk Image, and supported architecture(s).
NetBoot image sharepoints
NetBootSP1: path /Volumes/Storage/Library/NetBoot/NetBootSP1
NetBoot client sharepoints
NetBootClients0: path /Volumes/Storage/Library/NetBoot/NetBootClients0
Sharepoint   NameIdentifier Type      BootFile     Image(s)
NetBootSP1   3.2.2 PPC test0x81000621 NFS       booter       NetRestore.dmg [ppc]
NetBootSP1   3.2.2 test0x8100052a NFS       booter       NetRestore.dmg [i386]
NetBootSP1   iMac0x810001d6 NFS       booter       NetRestore.dmg [i386]
NetBootSP1   NetRestore0x81001389 NFS       booter       NetRestore.dmg [ppc]
NetBootSP1   Tiger Server0x81000065 NFS       booter       Install.dmg  [ppc]
NetBootSP1   Tiger0x810000c8 NFS       booter       Install.dmg  [ppc]
　　Finally, bootpd will read the client bindings database kept at/var/db/bsdpd_clients. When a client NetBoots and chooses the defaultNetBoot set, or when you choose a NetBoot set in the Startup DiskPreference Pane, the server records that choice in this bindingsdatabase keyed by client MAC address. In the following case, thebindings database is empty (has not been created yet).
/var/db/bsdpd_clients: No such file or directorydestination address 255.255.255.255


Client and Server Activity Upon Client's First Network Boot
　　The following transcript of bootpd output shows the communicationbetween a NetBooting client and a NetBoot server. In this particularcase, the client has never NetBooted from this server before, DHCP ishandled by another server, the NetBoot server and client are in thesame subnet, and there is only one NetBoot server within broadcastrange.
　　1) Client issues a DHCP DISCOVER
　　When a client machine issues a DHCP DISCOVER via broadcast, bootpdprints the following information. There are three notable sections inthis output: standard DHCP information (i.e. that covered by RFC 951),DHCP Vendor Options (i.e. that covered by RFC 2132), and BSDPExtensions (allowed by RFC 2132, but not documented outside the sourceof bootpd). In the following packet only, I have delineated thesesections with comment markers.
---------------- Client Request --------------------
### DHCP Info (RFC 951) ###
op = BOOTREQUEST
htype = 1
flags = 0
hlen = 6
hops = 0
xid = 37395
secs = 4
ciaddr = 0.0.0.0
yiaddr = 0.0.0.0
siaddr = 0.0.0.0
giaddr = 0.0.0.0
chaddr = 0:16:cb:ca:7b:35
sname =
file =

### DHCP Vendor Options (RFC 2132) ###
options:
Options count is 6
dhcp_message_type (uint8): DISCOVER 0x1
parameter_request_list (uint8_mult): {0x1, 0x3, 0x43, 0x2b, 0x3c}
client_identifier (uint8_mult): {0x1, 0x0, 0x16, 0xcb, 0xca, 0x7b, 0x35}
vendor_class_identifier (string): AAPLBSDPC/i386/MacBookPro1,1
vendor_specific (opaque):
0000  02 02 01 00                                      ....            

end (none):

### BSDP-specific Vendor Options ###
bootpd[27240]: BSDP DISCOVER [en0] 1,0:16:cb:ca:7b:35 arch=i386 sysid=MacBookPro1,1
BSDP Options count is 1
version: 0x100
bootpd[27240]: service time 0.000730 seconds
destination address 255.255.255.255
　　Additional discussion:
　　Of particular note is the information provided in the Vendor Optionssection. A NetBooting client must provide two pieces of information toelicit a response from a NetBoot server. First, it indicates its VendorClass as AAPLBSDPC, its architecture, and its system identificationstring as determined from firmware. Second, it requests the VendorClass (option 60, 0x3c) and Vendor Options (option 43, 0x2b) parametersin the parameter request list. When bootpd detects a DISCOVER packetwith these options requested, it determines if the client identifier(MAC address) has a record in the bindings database(/var/db/bsdpd_clients). The server response in the affirmative casewill be described later, in this case, the client does not have arecord in the bindings database and this packet is ignored by bootpd.
　　2) Client issues a DHCP REQUEST
　　Unseen prior to this packet is a DHCP OFFER packet that was sent tothe client from another DHCP server. While the DHCP OFFER was sent tothe broadcast address, it was sent to port 68, which only the client islistening to. bootpd is bound to port 67, which is the server-listeningport for DHCP and BSDP.
　　Here, the client issues a DHCP REQUEST for a specific IP address inresponse to another DHCP Server's DHCP OFFER. bootpd ignores thispacket as well in this case because it is not the server identified inthe server_identifier option.
---------------- Client Request --------------------
op = BOOTREQUEST
htype = 1
flags = 0
hlen = 6
hops = 0
xid = 37395
secs = 4
ciaddr = 0.0.0.0
yiaddr = 0.0.0.0
siaddr = 0.0.0.0
giaddr = 0.0.0.0
chaddr = 0:16:cb:ca:7b:35
sname =
file =
options:
Options count is 8
dhcp_message_type (uint8): REQUEST 0x3
parameter_request_list (uint8_mult): {0x1, 0x3, 0x43, 0x2b, 0x3c}
client_identifier (uint8_mult): {0x1, 0x0, 0x16, 0xcb, 0xca, 0x7b, 0x35}
vendor_class_identifier (string): AAPLBSDPC/i386/MacBookPro1,1
requested_ip_address (ip): 10.0.1.32
server_identifier (ip): 10.0.1.1
vendor_specific (opaque):
0000  02 02 01 00                                      ....            

end (none):
bootpd[27240]: service time 0.000403 seconds
destination address 10.0.1.11
　　3) Client issues a BSDP INFORM[LIST]
　　Having obtained an IP address and no BSDP response, the client nowadvertises its desire to collect a list of available NetBoot serversand NetBoot images. To elicit that response, it broadcasts an INFORMpacket with a BSDP "LIST" message.
---------------- Client Request --------------------
op = BOOTREQUEST
htype = 1
flags = 0
hlen = 6
hops = 0
xid = 37396
secs = 4
ciaddr = 10.0.1.32
yiaddr = 0.0.0.0
siaddr = 0.0.0.0
giaddr = 0.0.0.0
chaddr = 0:16:cb:ca:7b:35
sname =
file =
options:
Options count is 6
dhcp_message_type (uint8): INFORM 0x8
parameter_request_list (uint8_mult): {0x2b, 0x3c}
client_identifier (uint8_mult): {0x1, 0x0, 0x16, 0xcb, 0xca, 0x7b, 0x35}
vendor_class_identifier (string): AAPLBSDPC/i386/MacBookPro1,1
vendor_specific (opaque):
0000  01 01 01 02 02 01 00                             .......         

end (none):
bootpd[27240]: BSDP INFORM [en0] 1,0:16:cb:ca:7b:35 arch=i386 sysid=MacBookPro1,1
BSDP Options count is 2
message type: LIST (0x1)
version: 0x100
　　4) Server responds with a BSDP ACK[LIST]
　　The NetBoot server responds to the NetBoot client's LIST requestwith a BOOTREPLY that includes three BSDP options: Message type, serverpriority, and the ID of the default image that is available to thisparticular client. It is important to note that there can be multipledefault NetBoot sets indicated in Server Admin because the defaults arefiltered based on architecture and per-NetBoot-set Model filters. Onlyone image ID is returned to the client.
=================== Server Reply =====================
op = BOOTREPLY
htype = 1
flags = 0
hlen = 6
hops = 0
xid = 37396
secs = 0
ciaddr = 10.0.1.32
yiaddr = 0.0.0.0
siaddr = 10.0.1.11
giaddr = 0.0.0.0
chaddr = 0:16:cb:ca:7b:35
sname = pixel.roscoe.bombich.com
file =
options:
Options count is 5
dhcp_message_type (uint8): ACK 0x5
server_identifier (ip): 10.0.1.11
vendor_class_identifier (string): AAPLBSDPC
vendor_specific (opaque):
0000  01 01 01 04 02 80 00 07  04 81 00 05 2a           ............*   

end (none):
BSDP Options count is 3
message type: LIST (0x1)
server priority: 0x8000
default boot image: 0x8100052a
bootpd[27240]: NetBoot: [1,0:16:cb:ca:7b:35] BSDP ACK[LIST] sent 10.0.1.32 pktsize 300
bootpd[27240]: service time 0.001589 seconds
destination address 10.0.1.11
　　5) Client re-sends the INFORM[LIST] several times during collection mode
　　The client may resend the INFORM[LIST] packet several times duringthe discovery and collection phase to assure that it is getting acomplete list of available servers and NetBoot images (some servers maybe slower than others). This collection phase typically takes 2-4seconds. The NetBoot server responds to each LIST request with the sameACK[LIST] request as it responded with the first time.
　　The repeated packets are not listed here because the client requestsand server replies are exactly the same as in steps 3 and 4.
　　6) Client chooses a server and image and sends a BSDP INFORM[SELECT] message
　　Having collected a complete list of NetBoot servers, the clientchooses the server with the highest priority. The server's priority issimply a measurement of how many clients are listed in the NetBootbindings database (not necessarily the number of clients currentlybooted from the server). When the client has made this choice, itassembles a DHCP INFORM packet with the BSDP message_type option set toSELECT (0x02). Included in this response is the server ID and selectedboot image. This message is broadcast such that other NetBoot serversare aware of the choice as well. When a NetBoot server gets notice thatthe client has selected another NetBoot server, it deletes any bindingrecords for that client in the bindings database (that makes more senseif you consider the case of a user choosing a different NetBoot imagein the Startup Disk Preference Pane).
　　When bootpd receives an INFORM[SELECT] with the server ID matchingitself, it recognizes the appropriate reply file (booter) and preparesa response.
---------------- Client Request --------------------
op = BOOTREQUEST
htype = 1
flags = 0
hlen = 6
hops = 0
xid = 37396
secs = 7
ciaddr = 10.0.1.32
yiaddr = 0.0.0.0
siaddr = 0.0.0.0
giaddr = 0.0.0.0
chaddr = 0:16:cb:ca:7b:35
sname =
file =
options:
Options count is 6
dhcp_message_type (uint8): INFORM 0x8
parameter_request_list (uint8_mult): {0x2b, 0x3c}
client_identifier (uint8_mult): {0x1, 0x0, 0x16, 0xcb, 0xca, 0x7b, 0x35}
vendor_class_identifier (string): AAPLBSDPC/i386/MacBookPro1,1
vendor_specific (opaque):
0000  01 01 02 02 02 01 00 08  04 81 00 05 2a 03 04 0a  ............*...
0010  00 01 0b                                         ...            

end (none):
bootpd[27240]: BSDP INFORM [en0] 1,0:16:cb:ca:7b:35 arch=i386 sysid=MacBookPro1,1
BSDP Options count is 4
message type: SELECT (0x2)
version: 0x100
selected boot image: 0x8100052a
server identifier: 10.0.1.11
bootpd[27240]: replyfile /private/tftpboot/NetBoot/NetBootSP1/3.2.2 test.nbi/i386/booter
　　7) Server replies with an ACK[SELECT] packet containing NetBoot details
　　In response to an INFORM[SELECT] choosing this server, bootpdreplies with an ACK[SELECT]. This packet provides the client with theselected boot image ID, the machine name, the NetBoot image root path,and the path to the booter file. The client stores this entire packetin RAM for future reference during the boot process. bootpd thencreates a record for this client in the NetBoot bindings database.
=================== Server Reply =====================
op = BOOTREPLY
htype = 1
flags = 0
hlen = 6
hops = 0
xid = 37396
secs = 0
ciaddr = 10.0.1.32
yiaddr = 0.0.0.0
siaddr = 10.0.1.11
giaddr = 0.0.0.0
chaddr = 0:16:cb:ca:7b:35
sname = pixel.roscoe.bombich.com
file = /private/tftpboot/NetBoot/NetBootSP1/3.2.2 test.nbi/i386/booter
options:
Options count is 6
dhcp_message_type (uint8): ACK 0x5
server_identifier (ip): 10.0.1.11
vendor_class_identifier (string): AAPLBSDPC
root_path (string): nfs:10.0.1.11:/Volumes/Storage/Library/NetBoot/NetBootSP1:3.2.2 test.nbi/NetInstall-Restore.dmg
vendor_specific (opaque):
0000  01 01 02 08 04 81 00 05  2a 82 0a 4e 65 74 42 6f  ........*..NetBo
0010  6f 74 30 30 31                                   ot001           

end (none):
BSDP Options count is 3
message type: SELECT (0x2)
selected boot image: 0x8100052a
machine name: NetBoot001
bootpd[27240]: NetBoot: [1,0:16:cb:ca:7b:35] BSDP ACK[SELECT] sent 10.0.1.32 pktsize 381
bootpd[27240]: service time 0.004187 seconds


Client and Server Activity Upon Client's Subsequent Network Boot(s)
　　The communication that occurs between a NetBooting client and aNetBoot server on subsequent boots is much abbreviated compared to theinitial boot. In this particular case, the client has already NetBootedfrom this server before (it has a binding record in the server's/var/db/bsdpd_clients bindings database), DHCP is handled by anotherserver, the NetBoot server and client are in the same subnet, and thereis only one NetBoot server within broadcast range.
　　1) Client issues a DHCP DISCOVER
　　This is the exact same DISCOVER packet as in the previous section.This time, however, the server finds a match for the client ID in theNetBoot bindings database and recognizes a reply file for the client.It then prepares a reply to the client immediately.
---------------- Client Request --------------------
op = BOOTREQUEST
htype = 1
flags = 0
hlen = 6
hops = 0
xid = 37395
secs = 4
ciaddr = 0.0.0.0
yiaddr = 0.0.0.0
siaddr = 0.0.0.0
giaddr = 0.0.0.0
chaddr = 0:16:cb:ca:7b:35
sname =
file =
options:
Options count is 6
dhcp_message_type (uint8): DISCOVER 0x1
parameter_request_list (uint8_mult): {0x1, 0x3, 0x43, 0x2b, 0x3c}
client_identifier (uint8_mult): {0x1, 0x0, 0x16, 0xcb, 0xca, 0x7b, 0x35}
vendor_class_identifier (string): AAPLBSDPC/i386/MacBookPro1,1
vendor_specific (opaque):
0000  02 02 01 00                                      ....            

end (none):
bootpd[27259]: BSDP DISCOVER [en0] 1,0:16:cb:ca:7b:35 NetBoot001 arch=i386 sysid=MacBookPro1,1
BSDP Options count is 1
version: 0x100
bootpd[27259]: replyfile /private/tftpboot/NetBoot/NetBootSP1/3.2.2 test.nbi/i386/booter
bootpd[27259]: replying to 0.0.0.0
　　2) Server responds with a BSDP OFFER
　　Because the client already has a binding with this server, theserver issues a BSDP OFFER to the client. This offer containseverything the client needs to immediately begin NetBooting: a serveridentifier, a boot file path, a selected NetBoot image ID, a NetBootimage root path, and a machine name. Note that this OFFER is sent tothe broadcast address because the client does not yet have an IPaddress. The message is tagged with the client's MAC address, though,so only the requesting client will (should) use the message.
=================== Server Reply =====================
op = BOOTREPLY
htype = 1
flags = 0
hlen = 6
hops = 0
xid = 37395
secs = 0
ciaddr = 0.0.0.0
yiaddr = 0.0.0.0
siaddr = 10.0.1.11
giaddr = 0.0.0.0
chaddr = 0:16:cb:ca:7b:35
sname = pixel.roscoe.bombich.com
file = /private/tftpboot/NetBoot/NetBootSP1/3.2.2 test.nbi/i386/booter
options:
Options count is 6
dhcp_message_type (uint8): OFFER 0x2
server_identifier (ip): 10.0.1.11
vendor_class_identifier (string): AAPLBSDPC
root_path (string): nfs:10.0.1.11:/Volumes/Storage/Library/NetBoot/NetBootSP1:3.2.2 test.nbi/NetInstall-Restore.dmg
vendor_specific (opaque):
0000  08 04 81 00 05 2a 82 0a  4e 65 74 42 6f 6f 74 30  .....*..NetBoot0
0010  30 31                                            01              

end (none):
bootpd[27259]: BSDP OFFER sent [1,0:16:cb:ca:7b:35] pktsize 378
BSDP Options count is 2
selected boot image: 0x8100052a
machine name: NetBoot001
bootpd[27259]: service time 0.003723 seconds
destination address 255.255.255.255
　　3) Client sends a DHCP REQUEST to the DHCP server
　　This is the same request as in step two of the Initial BootSequence. This packet is ignored by the NetBoot server. As soon as theclient obtains an IP address, it begins phase two of the NetBootprocess.
---------------- Client Request --------------------
op = BOOTREQUEST
htype = 1
flags = 0
hlen = 6
hops = 0
xid = 37395
secs = 4
ciaddr = 0.0.0.0
yiaddr = 0.0.0.0
siaddr = 0.0.0.0
giaddr = 0.0.0.0
chaddr = 0:16:cb:ca:7b:35
sname =
file =
options:
Options count is 8
dhcp_message_type (uint8): REQUEST 0x3
parameter_request_list (uint8_mult): {0x1, 0x3, 0x43, 0x2b, 0x3c}
client_identifier (uint8_mult): {0x1, 0x0, 0x16, 0xcb, 0xca, 0x7b, 0x35}
vendor_class_identifier (string): AAPLBSDPC/i386/MacBookPro1,1
requested_ip_address (ip): 10.0.1.32
server_identifier (ip): 10.0.1.1
vendor_specific (opaque):
0000  02 02 01 00                                      ....            

end (none):
bootpd[27259]: service time 0.000414 seconds


Closing remarks
　　A while back I received an email from a colleague who had becomevery frustrated with NetBoot. He was trying to Netboot a MacBook Probut the machine simply refused -- it immediately rebooted from thelocal hard drive. After staring at packet traces, he finally asked if Icould help. My first question was, "Is the NetBoot server running atleast 10.4.4?". He said yes, it was running 10.4.5 Server. "And youcreated the images on an Intel machine, right?" The answer was yes. Itappeared that he was doing everything correctly. I gave himinstructions on putting the bootpd service in debug mode, and a fewminutes later he sent me the verbose output.
　　I immediately noticed that bootpd was not indicating anything about the architecture of the NetBoot imagespresent. I asked "Are you SURE the server is running 10.4.5?" Hedouble-checked, indeed it was running 10.4.5. I stared at the verboseoutput for a few more minutes, then concluded that, while they maythink they are running 10.4.5, they most certainly are not running thebootpd that came with it. When I suggested that something must havegone wrong with the update, the sysadmin of the server broke in andasked, "I recompiled the bootpd code myself, could that be causingproblems?" We had a good laugh over that one! After replacing thebootpd binary with a known good bootpd binary from another 10.4.5server, all was good.
　　You can troubleshoot many NetBoot issuesby simply watching what occurs on the screen of the Netbooting client.Troubleshooting the early stages of the NetBoot process, however, canbe a difficult task even when you have a screenful of packet traces.Fortunately, the daemon in charge of the NetBoot service, bootpd,digests much of this information and presents it to the systemadministrator in a readable form. With knowledge of how the BSDP"handshake" occurs, a reference of the various BSDP vendor-specificoptions, and examples of bootpd debug output, I hope you will be betterprepared to tackle challenging NetBoot issues.
　　References:
bootpd source code (Requires an ADC account)
bootpd man page
ADC on iTunes: WWDC 2006, Information Technologies Track, Session 517 NetBoot for Large Networks (Requires an ADC account)
Troubleshooting NetBoot from the client perspective
　　History:
4/13/2007: Initial publication
2/15/2008: Fixed several entries in the first table, they did not match the hex of the packet indicated above the table.