- 浏览: 1281288 次
文章分类
最新评论
-
极限_裁决:
第一题,a 没有定义全局变量不属于 window
第二题,由于 ...
你真懂JavaScript吗? -
netsupper:
1)a=1,答错了."a" in wind ...
你真懂JavaScript吗?
Mac OS X:Analysis of the Use of the Boot Server Discovery Protocol in NetBoot
Analysis of the Use of the Boot Server Discovery Protocol in NetBoot
Introduction
NetBoot uses the Boot Server Discovery Protocol (BSDP) to communicate network boot image options between clients and servers. BSDP is implemented within the Vendor Options of DHCP as defined in RFC 2132. Options not present within the DHCP specification are provided as vendor-specific information.
Understanding the content of the DHCP and BSDP communication between servers and clients can provide excellent insight for troubleshooting the NetBoot process. In this article I explain the components of a typical DHCP packet, dig deeper into the vendor options and BSDP-specific options, then I describe the NetBoot process from the NetBoot server perspective.
The following diagram provides a visual description of the flow of traffic between a NetBooting client, a DHCP server, and a NetBoot server during the initial phase of the NetBoot process.
The first half of this phase is a standard DHCP exchange. This article will not delve into a DHCP exchange, but it is worthwhile to understand the basic anatomy of a DHCP packet.
DHCP Packet -- Basic Components
The following is a DHCP ACK[SELECT] packet from a NetBoot server.
IP Header
4 = 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 at octet # 0x0104. This portion of the packet is defined by specifying the RFC 1048 "Magic Number" -- a sequence of numbers that indicates that the following portion of the packet is encoded as a sequence of code/length/value fields intended for transmitting vendor-specific information between clients and servers. I will take the packet trace from the previous page as an example:
To read the options in the vendor specific information option, start with the first octet after the magic number. Using the example above, "35" (hexadecimal) is the option "code", which, according to RFC 2132 corresponds to (ASCII 53) "DHCP Message". The length of the data in this option is "01" octets. The value of this option is contained within the next "01" octets which contains "05". This value is defined as 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, which represents the "Server ID" DHCP tag. The value type of that tag is IP notation, therefore the value translates to "10.0.1.11". The full translation of this packet is described in the following table.
35 (53) | DHCP Message | DHCP DISCOVER |
36 (54) | Server ID | 10.0.1.11 |
3c (60) | Vendor Class | AAPLBSDPC |
11 (17) | Root Path | nfs:10.0.1.11:/Volumes/Sto...Restore.dmg |
2b (43) | Vendor Options | 01010208 ... 74303031 |
The Vendor Options value is "opaque". While the format follows the same code/length/value format as the Vendor Specific Information option, the option codes are defined by the vendor rather than an RFC. NetBoot leverages the Vendor Options option for communicating BSDP messages between the server and the client.
Applying the same reading technique to the Vendor Options value, we can see that the packet contains BSDP options 1, 8, and 130 (0x82). By examining the bootpd source code (or simply its debug output), you can ascertain the tags for each of these codes so that you can understand the value of that option.
01 (1) | BSDP Message Type | SELECT |
08 (8) | Selected Boot Image | 0x8100052a (Image ID: 1322) |
82 (130) | Machine Name | NetBoot001 |
Other BSDP options that you will see used for NetBoot are listed in the following table.
1 | BSDP Message Type (1: LIST, 2: SELECT, 3: FAILED) |
2 | BSDP Version |
3 | Server ID |
4 | Server Priority |
5 | Reply Port |
7 | Default Boot Image |
8 | Selected Boot Image |
9 | Boot 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, but it is far easier to simply allow bootpd to provide the translated information via verbose mode, especially when it comes to deciphering the 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 such as 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 what you would normally see in the system.log file. The number in brackets is the process id of bootpd.
If you open the Startup Disk Preference Pane on a client machine, or NetBoot a client, then bootpd will activate. Upon activation, bootpd initializes any DHCP subnets based on information kept in NetInfo. It also reads any NetBoot configuration information kept in NetInfo. See the bootpd man page for more details on configuration information kept in 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 initializing subnets failed and that /var/db/dhcpd_leases does not exist. This is expected because, in this case, the NetBoot server is only providing the NetBoot service, not the DHCP service.
Upon initialization, bootpd will also search the configured NetBoot sharepoints for valid NetBoot sets. In verbose mode, each set is listed along 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 Name Identifier Type BootFile Image(s)
NetBootSP1 3.2.2 PPC test 0x81000621 NFS booter NetRestore.dmg [ppc]
NetBootSP1 3.2.2 test 0x8100052a NFS booter NetRestore.dmg [i386]
NetBootSP1 iMac 0x810001d6 NFS booter NetRestore.dmg [i386]
NetBootSP1 NetRestore 0x81001389 NFS booter NetRestore.dmg [ppc]
NetBootSP1 Tiger Server 0x81000065 NFS booter Install.dmg [ppc]
NetBootSP1 Tiger 0x810000c8 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 default NetBoot set, or when you choose a NetBoot set in the Startup Disk Preference Pane, the server records that choice in this bindings database keyed by client MAC address. In the following case, the bindings database is empty (has not been created yet).
/var/db/bsdpd_clients: No such file or directory destination address 255.255.255.255
Client and Server Activity Upon Client's First Network Boot
The following transcript of bootpd output shows the communication between a NetBooting client and a NetBoot server. In this particular case, the client has never NetBooted from this server before, DHCP is handled by another server, the NetBoot server and client are in the same subnet, and there is only one NetBoot server within broadcast range.
1) Client issues a DHCP DISCOVER
When a client machine issues a DHCP DISCOVER via broadcast, bootpd prints the following information. There are three notable sections in this output: standard DHCP information (i.e. that covered by RFC 951), DHCP Vendor Options (i.e. that covered by RFC 2132), and BSDP Extensions (allowed by RFC 2132, but not documented outside the source of bootpd). In the following packet only, I have delineated these sections 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 Options section. A NetBooting client must provide two pieces of information to elicit a response from a NetBoot server. First, it indicates its Vendor Class as AAPLBSDPC, its architecture, and its system identification string as determined from firmware. Second, it requests the Vendor Class (option 60, 0x3c) and Vendor Options (option 43, 0x2b) parameters in the parameter request list. When bootpd detects a DISCOVER packet with 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 case will be described later, in this case, the client does not have a record 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 to the client from another DHCP server. While the DHCP OFFER was sent to the broadcast address, it was sent to port 68, which only the client is listening to. bootpd is bound to port 67, which is the server-listening port for DHCP and BSDP.
Here, the client issues a DHCP REQUEST for a specific IP address in response to another DHCP Server's DHCP OFFER. bootpd ignores this packet as well in this case because it is not the server identified in the 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 now advertises its desire to collect a list of available NetBoot servers and NetBoot images. To elicit that response, it broadcasts an INFORM packet 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 request with a BOOTREPLY that includes three BSDP options: Message type, server priority, and the ID of the default image that is available to this particular client. It is important to note that there can be multiple default NetBoot sets indicated in Server Admin because the defaults are filtered based on architecture and per-NetBoot-set Model filters. Only one 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 during the discovery and collection phase to assure that it is getting a complete list of available servers and NetBoot images (some servers may be slower than others). This collection phase typically takes 2-4 seconds. The NetBoot server responds to each LIST request with the same ACK[LIST] request as it responded with the first time.
The repeated packets are not listed here because the client requests and 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 client chooses the server with the highest priority. The server's priority is simply a measurement of how many clients are listed in the NetBoot bindings database (not necessarily the number of clients currently booted from the server). When the client has made this choice, it assembles a DHCP INFORM packet with the BSDP message_type option set to SELECT (0x02). Included in this response is the server ID and selected boot image. This message is broadcast such that other NetBoot servers are aware of the choice as well. When a NetBoot server gets notice that the client has selected another NetBoot server, it deletes any binding records for that client in the bindings database (that makes more sense if you consider the case of a user choosing a different NetBoot image in the Startup Disk Preference Pane).
When bootpd receives an INFORM[SELECT] with the server ID matching itself, it recognizes the appropriate reply file (booter) and prepares a 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, bootpd replies with an ACK[SELECT]. This packet provides the client with the selected boot image ID, the machine name, the NetBoot image root path, and the path to the booter file. The client stores this entire packet in RAM for future reference during the boot process. bootpd then creates 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 a NetBoot server on subsequent boots is much abbreviated compared to the initial boot. In this particular case, the client has already NetBooted from this server before (it has a binding record in the server's /var/db/bsdpd_clients bindings database), DHCP is handled by another server, the NetBoot server and client are in the same subnet, and there is 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 the NetBoot 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, the server issues a BSDP OFFER to the client. This offer contains everything the client needs to immediately begin NetBooting: a server identifier, a boot file path, a selected NetBoot image ID, a NetBoot image root path, and a machine name. Note that this OFFER is sent to the broadcast address because the client does not yet have an IP address. 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 Boot Sequence. This packet is ignored by the NetBoot server. As soon as the client obtains an IP address, it begins phase two of the NetBoot process.
---------------- 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 become very frustrated with NetBoot. He was trying to Netboot a MacBook Pro but the machine simply refused -- it immediately rebooted from the local hard drive. After staring at packet traces, he finally asked if I could help. My first question was, "Is the NetBoot server running at least 10.4.4?". He said yes, it was running 10.4.5 Server. "And you created the images on an Intel machine, right?" The answer was yes. It appeared that he was doing everything correctly. I gave him instructions on putting the bootpd service in debug mode, and a few minutes later he sent me the verbose output.
I immediately noticed that bootpd was not indicating anything about the architecture of the NetBoot images present. I asked "Are you SURE the server is running 10.4.5?" He double-checked, indeed it was running 10.4.5. I stared at the verbose output for a few more minutes, then concluded that, while they may think they are running 10.4.5, they most certainly are not running the bootpd that came with it. When I suggested that something must have gone wrong with the update, the sysadmin of the server broke in and asked, "I recompiled the bootpd code myself, could that be causing problems?" We had a good laugh over that one! After replacing the bootpd binary with a known good bootpd binary from another 10.4.5 server, all was good.
You can troubleshoot many NetBoot issues by simply watching what occurs on the screen of the Netbooting client. Troubleshooting the early stages of the NetBoot process, however, can be 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 system administrator in a readable form. With knowledge of how the BSDP "handshake" occurs, a reference of the various BSDP vendor-specific options, and examples of bootpd debug output, I hope you will be better prepared 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.
相关推荐
netboot使用教程.docx
Netboot,用于网络启动的软件包和实用程序 该存储库包含用于通过网络引导计算机的网络协议的Go实现,以及在这些库之上构建的实用程序。 该项目不再积极开发。 如果您觉得它有用,很高兴,但是不要期望有任何重大...
Netboot.xyz完整的脱机存储 项目网址: : 这些脚本将准备的完整脱机副本。 我喜欢netboot.xyz ,并且当我无法访问能够进行网络引导的宽带网络时,我准备此脚本以使其具有脱机副本。 重要提示:此脚本将按原样...
NetSUS下载安装程序: : OVA: : 弃用通知Apple已弃用NetBoot和软件更新服务,因此该项目将不再接收进一步的更新。 该存储库将于2021年3月19日归档。什么是NetSUS? NetSUSLP允许您在同一Linux系统上托管内部软件...
netboot.xyz-custom 叉我! 此存储库将使您可以在netboot.xyz中创建自定义菜单。 它通过使用您输入的github用户名并链接到该URL来工作: https://raw.githubusercontent.com/${github_user}/netboot.xyz-custom/...
toaru-netboot:为ToaruOS制作网络引导映像的工具
网络引导配置文件,不用自己去写配置,适用于redhat,centos,ubuntu,linuxmint
: :green_square: 所有系统均可运行 这个软件库包含了开源的正常运行时间监测和状态页 ,搭载 。 借助 ,您可以获得自己不受限制的免费正常运行时间监控器和状态页面,该页面完全由GitHub存储库提供支持。...
netboot/i 是一款国外知名的网络虚拟存储启动系统,它可以将 iscsi 的虚拟盘“变成”可以通过 PXE 启动系统的企业级软件,对于有盘而言 iscsi 也并不陌生,国内几款知名的有盘网吧系统都集成了 iscsi 的虚拟磁盘系统...
netboot.xyz:基于iPXE的网络可引导操作系统安装程序
netboot.ipfs:基于网络的操作系统安装程序
适用于旧世界Mac的netBOOT 阅读此线程: : 现在,我正在尝试使其正常运行! 梦想是通过PhoneNet引导我的所有Classics。 到目前为止的进展 Mini vMac的最佳构建选项是: -br 37 -m Classic -lt -speed z -as 0 -...
CLI工具已移至 {fbnetboot,localboot,uinit}下,库已移至[u-root / pkg /] {bootconfig,booter,checker,crypto,recovery,rng,storage,vpd}下。 和 。 SystemBoot是LinuxBoot的发行版,用于创建系统固件+...
非常好用的一款DHCP软件,启动软件后,在设置里面选择本地网卡,IP范围等参数,对端连接需要分配IP地址的客户端,启动软件后大约10秒内就能分配到IP。操作简单易用。
$ ./boot_root_nfs server:/netboot/10-stable / -e boot.nfsroot.server=192.0.2.1 -e boot.nfsroot.nfshandle=Xffd8bce2de73f4a90a000400000000005e860b000000000000000000X -e boot.nfsroot.nfshandlelen=28 -e ...
用于 OSX Netboot 固件的 tftpboot概念这个 repo 包含文件 + dnsmasq 配置,可用于... 只需使用 os x 服务器或安装现有的 os x 即可免费创建此映像。苹果破坏的 tftp 实现在此设置过程中,我确实体验到 mac 固件的 tft
netboot.nix:15秒的netboot迭代 如何使用 在您的构建器上设置递归nix(请参见下文) 添加quickly.nix到系统的进口,像./size-test/base.nix 然后构建您的iPXE引导目录: $ nix-build '<nixpkgs>' -I nixos-...
netboot.xyz-custom 叉我! 此存储库将使您可以在netboot.xyz中创建自定义菜单。 它通过使用您输入的github用户名并链接到该URL来工作: https://raw.githubusercontent.com/${github_user}/netboot.xyz-custom/...
),假设您已经按照 FreeBSD 手册中的描述配置了 pxe-filesystem-server:https://docs.freebsd.org / zh-CN / books / handbook / advanced-networking /#network-diskless您无需将u-boot或固件放入pxe-server。...
PXESetupWizard:PXE安装向导。 Netboot Debian,Ubuntu,System Rescue CD,FreeDOS等