# 本人第一次电子出版，《bootp远程启动大全》

**URL:** <https://netpcforum.org/t/%E6%9C%AC%E4%BA%BA%E7%AC%AC%E4%B8%80%E6%AC%A1%E7%94%B5%E5%AD%90%E5%87%BA%E7%89%88%EF%BC%8C%E3%80%8Abootp%E8%BF%9C%E7%A8%8B%E5%90%AF%E5%8A%A8%E5%A4%A7%E5%85%A8%E3%80%8B/87688>\
**Category:** 无盘论坛\
**Created:** [2002 年11 月 24 日 15:22 UTC](https://netpcforum.org/t/%E6%9C%AC%E4%BA%BA%E7%AC%AC%E4%B8%80%E6%AC%A1%E7%94%B5%E5%AD%90%E5%87%BA%E7%89%88%EF%BC%8C%E3%80%8Abootp%E8%BF%9C%E7%A8%8B%E5%90%AF%E5%8A%A8%E5%A4%A7%E5%85%A8%E3%80%8B/87688 "2002-11-24T15:22:15Z")\
**Posts on this page:** 20\
**Page:** 2

<div class="post-metadata">

作者： ![liu\_huajin](https://assets.netpcforum.org/letter_avatar_proxy/v4/letter/l/cab0a1/32.png) [@liu\_huajin](https://netpcforum.org/u/liu_huajin)\
发布日期： [2002 年11 月 26 日 02:50 UTC](https://netpcforum.org/t/%E6%9C%AC%E4%BA%BA%E7%AC%AC%E4%B8%80%E6%AC%A1%E7%94%B5%E5%AD%90%E5%87%BA%E7%89%88%EF%BC%8C%E3%80%8Abootp%E8%BF%9C%E7%A8%8B%E5%90%AF%E5%8A%A8%E5%A4%A7%E5%85%A8%E3%80%8B/87688/21 "2002-11-26T02:50:38Z")

</div>

🙂  
老大,你好劲呀,如此功力,使我大深深佩服,就好像教练一样.

---

<div class="post-metadata">

作者： ![panhh](https://assets.netpcforum.org/letter_avatar_proxy/v4/letter/p/a9a28c/32.png) [@panhh](https://netpcforum.org/u/panhh)\
发布日期： [2002 年11 月 26 日 04:23 UTC](https://netpcforum.org/t/%E6%9C%AC%E4%BA%BA%E7%AC%AC%E4%B8%80%E6%AC%A1%E7%94%B5%E5%AD%90%E5%87%BA%E7%89%88%EF%BC%8C%E3%80%8Abootp%E8%BF%9C%E7%A8%8B%E5%90%AF%E5%8A%A8%E5%A4%A7%E5%85%A8%E3%80%8B/87688/22 "2002-11-26T04:23:10Z")

</div>

> [@太狼](#):
>
> PANHH你好。  
> 我看了你的BOOTP。CHM大有所获。  
> 突然有做BOOTP的冲动。  
> 但是我没有mknbi。 我搜了老贴，原来的下载连接以不能用了！  
> 你能发我一个吗？？  
> [hhshanwei@163.com](mailto:hhshanwei@163.com)
> 
> 或者上传到
> 
> ftp://netpc:netpc@netpc.whidc.com  
> 谢谢!

都在我的ftp://xgjx.vicp.net/bootp中

---

<div class="post-metadata">

作者： ![panhh](https://assets.netpcforum.org/letter_avatar_proxy/v4/letter/p/a9a28c/32.png) [@panhh](https://netpcforum.org/u/panhh)\
发布日期： [2002 年11 月 26 日 04:25 UTC](https://netpcforum.org/t/%E6%9C%AC%E4%BA%BA%E7%AC%AC%E4%B8%80%E6%AC%A1%E7%94%B5%E5%AD%90%E5%87%BA%E7%89%88%EF%BC%8C%E3%80%8Abootp%E8%BF%9C%E7%A8%8B%E5%90%AF%E5%8A%A8%E5%A4%A7%E5%85%A8%E3%80%8B/87688/23 "2002-11-26T04:25:15Z")

</div>

> [@life](#):
>
> 老大我的网卡是DM9008的网卡，而[http://rom-o-matic.net上只有DM9009的请问两者是否可换用](http://rom-o-matic.xn--netDM9009-sb6nejk52dcc55bf24pymjxsdq61g0nflm7c0o2cr25b)。

我也不清楚，但方法我已经说了，就是下载制作模拟软盘，试了不就知道了。

---

<div class="post-metadata">

作者： ![life](https://assets.netpcforum.org/letter_avatar_proxy/v4/letter/l/439d5e/32.png) [@life](https://netpcforum.org/u/life)\
发布日期： [2002 年11 月 26 日 07:58 UTC](https://netpcforum.org/t/%E6%9C%AC%E4%BA%BA%E7%AC%AC%E4%B8%80%E6%AC%A1%E7%94%B5%E5%AD%90%E5%87%BA%E7%89%88%EF%BC%8C%E3%80%8Abootp%E8%BF%9C%E7%A8%8B%E5%90%AF%E5%8A%A8%E5%A4%A7%E5%85%A8%E3%80%8B/87688/24 "2002-11-26T07:58:36Z")

</div>

> [@网之鹰](#):
>
> 9008 肯定有 我以前试过的。

网之鹰版主，没有9008呀，用NE2000的可以吗？

---

<div class="post-metadata">

作者： ![life](https://assets.netpcforum.org/letter_avatar_proxy/v4/letter/l/439d5e/32.png) [@life](https://netpcforum.org/u/life)\
发布日期： [2002 年11 月 26 日 14:14 UTC](https://netpcforum.org/t/%E6%9C%AC%E4%BA%BA%E7%AC%AC%E4%B8%80%E6%AC%A1%E7%94%B5%E5%AD%90%E5%87%BA%E7%89%88%EF%BC%8C%E3%80%8Abootp%E8%BF%9C%E7%A8%8B%E5%90%AF%E5%8A%A8%E5%A4%A7%E5%85%A8%E3%80%8B/87688/25 "2002-11-26T14:14:53Z")

</div>

> [@panhh](#):
>
> > [@life](#):
> >
> > 老大我的网卡是DM9008的网卡，而[http://rom-o-matic.net上只有DM9009的请问两者是否可换用](http://rom-o-matic.xn--netDM9009-sb6nejk52dcc55bf24pymjxsdq61g0nflm7c0o2cr25b)。
> 
> 我也不清楚，但方法我已经说了，就是下载制作模拟软盘，试了不就知道了。

老大，谢谢你的文章。我的DM9008原来就是NE2000兼容网卡，我今天试过了，谢谢。

---

<div class="post-metadata">

作者： ![life](https://assets.netpcforum.org/letter_avatar_proxy/v4/letter/l/439d5e/32.png) [@life](https://netpcforum.org/u/life)\
发布日期： [2002 年11 月 28 日 08:52 UTC](https://netpcforum.org/t/%E6%9C%AC%E4%BA%BA%E7%AC%AC%E4%B8%80%E6%AC%A1%E7%94%B5%E5%AD%90%E5%87%BA%E7%89%88%EF%BC%8C%E3%80%8Abootp%E8%BF%9C%E7%A8%8B%E5%90%AF%E5%8A%A8%E5%A4%A7%E5%85%A8%E3%80%8B/87688/26 "2002-11-28T08:52:47Z")

</div>

panhh兄，如何在服务器上获取工作站的网卡的MAC地址呢？如果有办法，我想就有希望做成象启明星一样的管理器了。

---

<div class="post-metadata">

作者： ![panhh](https://assets.netpcforum.org/letter_avatar_proxy/v4/letter/p/a9a28c/32.png) [@panhh](https://netpcforum.org/u/panhh)\
发布日期： [2002 年11 月 28 日 09:17 UTC](https://netpcforum.org/t/%E6%9C%AC%E4%BA%BA%E7%AC%AC%E4%B8%80%E6%AC%A1%E7%94%B5%E5%AD%90%E5%87%BA%E7%89%88%EF%BC%8C%E3%80%8Abootp%E8%BF%9C%E7%A8%8B%E5%90%AF%E5%8A%A8%E5%A4%A7%E5%85%A8%E3%80%8B/87688/27 "2002-11-28T09:17:24Z")

</div>

在bootp/dhcpl等等协议中，最初无盘站启动时都要向服务器发送一个寻找ip的帧，只要编程监听对应的服务器端口，就可以得到无盘站启动时的帧其中就是相应的mac地址。linux中有bootp/dhcp有源程序，就看你能不能读懂，能不能自己编写了。  
所有协议都是公开的，只不过要读E文了。

---

<div class="post-metadata">

作者： ![panhh](https://assets.netpcforum.org/letter_avatar_proxy/v4/letter/p/a9a28c/32.png) [@panhh](https://netpcforum.org/u/panhh)\
发布日期： [2002 年11 月 28 日 09:19 UTC](https://netpcforum.org/t/%E6%9C%AC%E4%BA%BA%E7%AC%AC%E4%B8%80%E6%AC%A1%E7%94%B5%E5%AD%90%E5%87%BA%E7%89%88%EF%BC%8C%E3%80%8Abootp%E8%BF%9C%E7%A8%8B%E5%90%AF%E5%8A%A8%E5%A4%A7%E5%85%A8%E3%80%8B/87688/28 "2002-11-28T09:19:52Z")

</div>

Network Working Group Bill Croft (Stanford University)  
Request for Comments: 951 John Gilmore (Sun Microsystems)  
September 1985

```
                   BOOTSTRAP PROTOCOL (BOOTP)

```

1. Status of this Memo

2. Overview

RFC 951 September 1985  
Bootstrap Protocol

```
  3. The request can optionally contain the name of the server the
  client wishes to respond. This is so the client can force the
  boot to occur from a specific host (e.g. if multiple versions of
  the same bootfile exist or if the server is in a far distant
  net/domain). The client does not have to deal with name / domain
  services; instead this function is pushed off to the BOOTP server.

  4. The request can optionally contain the 'generic' filename to be
  booted. For example 'unix' or 'ethertip'. When the server sends
  the bootreply, it replaces this field with the fully qualified
  path name of the appropriate boot file. In determining this name,
  the server may consult his own database correlating the client's
  address and filename request, with a particular boot file
  customized for that client. If the bootrequest filename is a null
  string, then the server returns a filename field indicating the
  'default' file to be loaded for that client.

  5. In the case of clients who do not know their IP addresses, the
  server must also have a database relating hardware address to IP
  address. This client IP address is then placed into a field in
  the bootreply.

  6. Certain network topologies (such as Stanford's) may be such
  that a given physical cable does not have a TFTP server directly
  attached to it (e.g. all the gateways and hosts on a certain cable
  may be diskless). With the cooperation of neighboring gateways,
  BOOTP can allow clients to boot off of servers several hops away,
  through these gateways. See the section 'Booting Through
  Gateways' below. This part of the protocol requires no special
  action on the part of the client. Implementation is optional and
  requires a small amount of additional code in gateways and
  servers.

```

1. Packet Format

RFC 951 September 1985  
Bootstrap Protocol

The UDP header contains source and destination port numbers. The  
BOOTP protocol uses two reserved port numbers, ‘BOOTP client’ (68)  
and ‘BOOTP server’ (67). The client sends requests using ‘BOOTP  
server’ as the destination port; this is usually a broadcast. The  
server sends replies using ‘BOOTP client’ as the destination port;  
depending on the kernel or driver facilities in the server, this may  
or may not be a broadcast (this is explained further in the section  
titled ‘Chicken/Egg issues’ below). The reason TWO reserved ports  
are used, is to avoid ‘waking up’ and scheduling the BOOTP server  
daemons, when a bootreply must be broadcast to a client. Since the  
server and other hosts won’t be listening on the ‘BOOTP client’ port,  
any such incoming broadcasts will be filtered out at the kernel  
level. We could not simply allow the client to pick a ‘random’ port  
number for the UDP source port field; since the server reply may be  
broadcast, a randomly chosen port number could confuse other hosts  
that happened to be listening on that port.

The UDP length field is set to the length of the UDP plus BOOTP  
portions of the packet. The UDP checksum field can be set to zero by  
the client (or server) if desired, to avoid this extra overhead in a  
PROM implementation. In the ‘Packet Processing’ section below the  
phrase ‘[UDP checksum.]’ is used whenever the checksum might be  
verified/computed.

```
  FIELD BYTES DESCRIPTION
  ----- ----- -----------

     op 1 packet op code / message type.
                     1 = BOOTREQUEST, 2 = BOOTREPLY

     htype 1 hardware address type,
                     see ARP section in "Assigned Numbers" RFC.
                     '1' = 10mb ethernet

     hlen 1 hardware address length
                     (eg '6' for 10mb ethernet).

     hops 1 client sets to zero,
                     optionally used by gateways
                     in cross-gateway booting.

     xid 4 transaction ID, a random number,
                     used to match this boot request with the
                     responses it generates.

     secs 2 filled in by client, seconds elapsed since
                     client started trying to boot.

```

RFC 951 September 1985  
Bootstrap Protocol

```
     -- 2 unused

     ciaddr 4 client IP address;
                     filled in by client in bootrequest if known.

     yiaddr 4 'your' (client) IP address;
                     filled by server if client doesn't
                     know its own address (ciaddr was 0).

     siaddr 4 server IP address;
                     returned in bootreply by server.

     giaddr 4 gateway IP address,
                     used in optional cross-gateway booting.

     chaddr 16 client hardware address,
                     filled in by client.

     sname 64 optional server host name,
                     null terminated string.

     file 128 boot file name, null terminated string;
                     'generic' name or null in bootrequest,
                     fully qualified directory-path
                     name in bootreply.

     vend 64 optional vendor-specific area,
                     e.g. could be hardware type/serial on request,
                     or 'capability' / remote file system handle
                     on reply. This info may be set aside for use
                     by a third phase bootstrap or kernel.

```

1. Chicken / Egg Issues

RFC 951 September 1985  
Bootstrap Protocol

```
     to 'manually' construct an ARP address cache entry, then it can
     fill in an entry using the 'chaddr' and 'yiaddr' fields. Of
     course, this entry should have a timeout on it, just like any
     other entry made by the normal ARP code itself. The
     transmitter of the bootreply can then simply send the bootreply
     to the client's IP address. UNIX (4.2 BSD) has this
     capability.

     b. If the transmitter lacks these kernel hooks, it can simply
     send the bootreply to the IP broadcast address on the
     appropriate interface. This is only one additional broadcast
     over the previous case.

```

1. Client Use of ARP

2. Comparison to RARP

RFC 951 September 1985  
Bootstrap Protocol

1. Packet Processing

RFC 951 September 1985  
Bootstrap Protocol

```
  'gateway'; this means 'boot the named program configured for my
  machine'. Finally the field can be a fully directory qualified
  path name.

  The 'vend' field can be filled in by the client with
  vendor-specific strings or structures. For example the machine
  hardware type or serial number may be placed here. However the
  operation of the BOOTP server should not DEPEND on this
  information existing.

  If the 'vend' field is used, it is recommended that a 4 byte
  'magic number' be the first item within 'vend'. This lets a
  server determine what kind of information it is seeing in this
  field. Numbers can be assigned by the usual 'magic number'
  process --you pick one and it's magic. A different magic number
  could be used for bootreply's than bootrequest's to allow the
  client to take special action with the reply information.

  [UDP checksum.]

```

7.2. Client Retransmission Strategy

```
  If no reply is received for a certain length of time, the client
  should retransmit the request. The time interval must be chosen
  carefully so as not to flood the network. Consider the case of a
  cable containing 100 machines that are just coming up after a
  power failure. Simply retransmitting the request every four
  seconds will inundate the net.

  As a possible strategy, you might consider backing off
  exponentially, similar to the way ethernet backs off on a
  collision. So for example if the first packet is at time 0:00,
  the second would be at :04, then :08, then :16, then :32, then
  :64. You should also randomize each time; this would be done
  similar to the ethernet specification by starting with a mask and
  'and'ing that with with a random number to get the first backoff.
  On each succeeding backoff, the mask is increased in length by one
  bit. This doubles the average delay on each backoff.

  After the 'average' backoff reaches about 60 seconds, it should be
  increased no further, but still randomized.

  Before each retransmission, the client should update the 'secs'
  field. [UDP checksum.]

```

RFC 951 September 1985  
Bootstrap Protocol

7.3. Server Receives BOOTREQUEST

```
  [UDP checksum.] If the UDP destination port does not match the
  'BOOTP server' port, discard the packet.

  If the server name field (sname) is null (no particular server
  specified), or sname is specified and matches our name or
  nickname, then continue with packet processing.

  If the sname field is specified, but does not match 'us', then
  there are several options:

     1. You may choose to simply discard this packet.

     2. If a name lookup on sname shows it to be on this same cable,
     discard the packet.

     3. If sname is on a different net, you may choose to forward
     the packet to that address. If so, check the 'giaddr' (gateway
     address) field. If 'giaddr' is zero, fill it in with my
     address or the address of a gateway that can be used to get to
     that net. Then forward the packet.

  If the client IP address (ciaddr) is zero, then the client does
  not know its own IP address. Attempt to lookup the client
  hardware address (chaddr, hlen, htype) in our database. If no
  match is found, discard the packet. Otherwise we now have an IP
  address for this client; fill it into the 'yiaddr' (your IP
  address) field.

  We now check the boot file name field (file). The field will be
  null if the client is not interested in filenames, or wants the
  default bootfile. If the field is non-null, it is used as a
  lookup key in a database, along with the client's IP address. If
  there is a default file or generic file (possibly indexed by the
  client address) or a fully-specified path name that matches, then
  replace the 'file' field with the fully-specified path name of the
  selected boot file. If the field is non-null and no match was
  found, then the client is asking for a file we dont have; discard
  the packet, perhaps some other BOOTP server will have it.

  The 'vend' vendor-specific data field should now be checked and if
  a recognized type of data is provided, client-specific actions
  should be taken, and a response placed in the 'vend' data field of
  the reply packet. For example, a workstation client could provide

```

RFC 951 September 1985  
Bootstrap Protocol

```
  an authentication key and receive from the server a capability for
  remote file access, or a set of configuration options, which can
  be passed to the operating system that will shortly be booted in.

  Place my (server) IP address in the 'siaddr' field. Set the 'op'
  field to BOOTREPLY. The UDP destination port is set to 'BOOTP
  client'. If the client address 'ciaddr' is nonzero, send the
  packet there; else if the gateway address 'giaddr' is nonzero, set
  the UDP destination port to 'BOOTP server' and send the packet to
  'giaddr'; else the client is on one of our cables but it doesnt
  know its own IP address yet --use a method described in the 'Egg'
  section above to send it to the client. If 'Egg' is used and we
  have multiple interfaces on this host, use the 'yiaddr' (your IP
  address) field to figure out which net (cable/interface) to send
  the packet to. [UDP checksum.]

```

7.4. Server/Gateway Receives BOOTREPLY

```
  [UDP checksum.] If 'yiaddr' (your [the client's] IP address)
  refers to one of our cables, use one of the 'Egg' methods above to
  forward it to the client. Be sure to send it to the 'BOOTP
  client' UDP destination port.

```

7.5. Client Reception

```
  Don't forget to process ARP requests for my own IP address (if I
  know it). [UDP checksum.] The client should discard incoming
  packets that: are not IP/UDPs addressed to the boot port; are not
  BOOTREPLYs; do not match my IP address (if I know it) or my
  hardware address; do not match my transaction id. Otherwise we
  have received a successful reply. 'yiaddr' will contain my IP
  address, if I didnt know it before. 'file' is the name of the
  file name to TFTP 'read request'. The server address is in
  'siaddr'. If 'giaddr' (gateway address) is nonzero, then the
  packets should be forwarded there first, in order to get to the
  server.

```

1. Booting Through Gateways

RFC 951 September 1985  
Bootstrap Protocol

gateway could have, as part of his configuration tables, a list of  
other networks or hosts to receive a copy of any broadcast  
BOOTREQUESTs. Even though a ‘hops’ field exists, it is a poor idea  
to simply globally rebroadcast the requests, since broadcast loops  
will almost certainly occur.

The forwarding could begin immediately, or wait until the ‘secs’  
(seconds client has been trying) field passes a certain threshold.

If a gateway does decide to forward the request, it should look at  
the ‘giaddr’ (gateway IP address) field. If zero, it should plug its  
own IP address (on the receiving cable) into this field. It may also  
use the ‘hops’ field to optionally control how far the packet is  
reforwarded. Hops should be incremented on each forwarding. For  
example, if hops passes ‘3’, the packet should probably be discarded.  
[UDP checksum.]

Here we have recommended placing this special forwarding function in  
the gateways. But that does not have to be the case. As long as  
some ‘BOOTP forwarding agent’ exists on the net with the booting  
client, the agent can do the forwarding when appropriate. Thus this  
service may or may not be co-located with the gateway.

In the case of a forwarding agent not located in the gateway, the  
agent could save himself some work by plugging the broadcast address  
of the interface receiving the bootrequest into the ‘giaddr’ field.  
Thus the reply would get forwarded using normal gateways, not  
involving the forwarding agent. Of course the disadvantage here is  
that you lose the ability to use the ‘Egg’ non-broadcast method of  
sending the reply, causing extra overhead for every host on the  
client cable.

1. Sample BOOTP Server Database

RFC 951 September 1985  
Bootstrap Protocol

appropriate to that generic name. If that file is not found, then  
the plain ‘pathname’ will be tried. This ‘suffix’ option allows a  
whole set of custom generics to be setup without a lot of effort.  
Below is shown the general format; fields are delimited by one or  
more spaces or tabs; trailing empty fields may be omitted; blank  
lines and lines beginning with ‘#’ are ignored.

```
  # comment line

  homedirectory
  genericname1 pathname1
  genericname2 pathname2
  ...

  % end of generic names, start of address mappings

  hostname1 hardwaretype hardwareaddr1 ipaddr1 genericname suffix
  hostname2 hardwaretype hardwareaddr2 ipaddr2 genericname suffix
  ...

```

Here is a specific example. Note the ‘hardwaretype’ number is the  
same as that shown in the ARP section of the ‘Assigned Numbers’ RFC.  
The ‘hardwaretype’ and ‘ipaddr’ numbers are in decimal;  
‘hardwareaddr’ is in hex.

```
  # last updated by smith

  /usr/boot
  vmunix vmunix
  tip ethertip
  watch /usr/diag/etherwatch
  gate gate.

  % end of generic names, start of address mappings

  hamilton 1 02.60.8c.06.34.98 36.19.0.5
  burr 1 02.60.8c.34.11.78 36.44.0.12
  101-gateway 1 02.60.8c.23.ab.35 36.44.0.32 gate 101
  mjh-gateway 1 02.60.8c.12.32.bc 36.42.0.64 gate mjh
  welch-tipa 1 02.60.8c.22.65.32 36.47.0.14 tip
  welch-tipb 1 02.60.8c.12.15.c8 36.46.0.12 tip

```

In the example above, if ‘mjh-gateway’ does a default boot, it will  
get the file ‘/usr/boot/gate.mjh’.

RFC 951 September 1985  
Bootstrap Protocol

1. Acknowledgements

Ross Finlayson (et. al.) produced two earlier RFC’s discussing TFTP  
bootstraping [2] using RARP [1].

We would also like to acknowledge the previous work and comments of  
Noel Chiappa, Bob Lyon, Jeff Mogul, Mark Lewis, and David Plummer.

REFERENCES

1. Ross Finlayson, Timothy Mann, Jeffrey Mogul, Marvin Theimer. A  
Reverse Address Resolution Protocol. RFC 903, NIC, June, 1984.

2. Ross Finlayson. Bootstrap Loading using TFTP. RFC 906, NIC,  
June, 1984.

3. Mark Lottor. Simple File Transfer Protocol. RFC 913, NIC,  
September, 1984.

4. Jeffrey Mogul. Broadcasting Internet Packets. RFC 919, NIC,  
October, 1984.

5. David Plummer. An Ethernet Address Resolution Protocol. RFC  
826, NIC, September, 1982.

6. Jon Postel. File Transfer Protocol. RFC 765, NIC, June, 1980.

7. Jon Postel. User Datagram Protocol. RFC 768, NIC, August, 1980.

8. Jon Postel. Internet Protocol. RFC 791, NIC, September, 1981.

9. K. R. Sollins, Noel Chiappa. The TFTP Protocol. RFC 783, NIC,  
June, 1981.

---

<div class="post-metadata">

作者： ![life](https://assets.netpcforum.org/letter_avatar_proxy/v4/letter/l/439d5e/32.png) [@life](https://netpcforum.org/u/life)\
发布日期： [2002 年11 月 28 日 14:32 UTC](https://netpcforum.org/t/%E6%9C%AC%E4%BA%BA%E7%AC%AC%E4%B8%80%E6%AC%A1%E7%94%B5%E5%AD%90%E5%87%BA%E7%89%88%EF%BC%8C%E3%80%8Abootp%E8%BF%9C%E7%A8%8B%E5%90%AF%E5%8A%A8%E5%A4%A7%E5%85%A8%E3%80%8B/87688/29 "2002-11-28T14:32:28Z")

</div>

panhh兄，谢谢你的贴子，E文是比较难懂，慢慢看应该没有问题。以后若有什么不懂还需要你的指教。谢过了。

---

<div class="post-metadata">

作者： ![笑笑生](https://assets.netpcforum.org/letter_avatar_proxy/v4/letter/%E7%AC%91/c5a1d2/32.png) [@笑笑生](https://netpcforum.org/u/%E7%AC%91%E7%AC%91%E7%94%9F)\
发布日期： [2002 年11 月 29 日 00:39 UTC](https://netpcforum.org/t/%E6%9C%AC%E4%BA%BA%E7%AC%AC%E4%B8%80%E6%AC%A1%E7%94%B5%E5%AD%90%E5%87%BA%E7%89%88%EF%BC%8C%E3%80%8Abootp%E8%BF%9C%E7%A8%8B%E5%90%AF%E5%8A%A8%E5%A4%A7%E5%85%A8%E3%80%8B/87688/30 "2002-11-29T00:39:11Z")

</div>

OK!DOWN！！！ 😆

---

<div class="post-metadata">

作者： ![红晨](https://assets.netpcforum.org/letter_avatar_proxy/v4/letter/%E7%BA%A2/45deac/32.png) [@红晨](https://netpcforum.org/u/%E7%BA%A2%E6%99%A8)\
发布日期： [2002 年11 月 30 日 02:48 UTC](https://netpcforum.org/t/%E6%9C%AC%E4%BA%BA%E7%AC%AC%E4%B8%80%E6%AC%A1%E7%94%B5%E5%AD%90%E5%87%BA%E7%89%88%EF%BC%8C%E3%80%8Abootp%E8%BF%9C%E7%A8%8B%E5%90%AF%E5%8A%A8%E5%A4%A7%E5%85%A8%E3%80%8B/87688/31 "2002-11-30T02:48:48Z")

</div>

是不是我来晚了。

---

<div class="post-metadata">

作者： ![panhh](https://assets.netpcforum.org/letter_avatar_proxy/v4/letter/p/a9a28c/32.png) [@panhh](https://netpcforum.org/u/panhh)\
发布日期： [2002 年12 月 2 日 13:05 UTC](https://netpcforum.org/t/%E6%9C%AC%E4%BA%BA%E7%AC%AC%E4%B8%80%E6%AC%A1%E7%94%B5%E5%AD%90%E5%87%BA%E7%89%88%EF%BC%8C%E3%80%8Abootp%E8%BF%9C%E7%A8%8B%E5%90%AF%E5%8A%A8%E5%A4%A7%E5%85%A8%E3%80%8B/87688/32 "2002-12-02T13:05:26Z")

</div>

ftp://xgjx.vicp.net/bootp  
中的压缩包已能下载了。

---

<div class="post-metadata">

作者： ![YOSHIMITSU](https://assets.netpcforum.org/letter_avatar_proxy/v4/letter/y/ec9cab/32.png) [@YOSHIMITSU](https://netpcforum.org/u/YOSHIMITSU)\
发布日期： [2002 年12 月 2 日 15:11 UTC](https://netpcforum.org/t/%E6%9C%AC%E4%BA%BA%E7%AC%AC%E4%B8%80%E6%AC%A1%E7%94%B5%E5%AD%90%E5%87%BA%E7%89%88%EF%BC%8C%E3%80%8Abootp%E8%BF%9C%E7%A8%8B%E5%90%AF%E5%8A%A8%E5%A4%A7%E5%85%A8%E3%80%8B/87688/33 "2002-12-02T15:11:48Z")

</div>

拜读大作，甚感欢欣。  
这比bootix的文档实用很多，更没有语言障碍。

补充重要一点：在NT及9X下，默认情况是UDP 67给DHCP或BOOTP，UDP 68未打开，因此在NT及9X下直接使用bootpd32.exe，必然出错，无法运行，只有在services文件中定义此二UDP端口，才可正常使用。在W2K及XP下无需此步。ME下不知。

望老兄考虑写入之，因为好多人更愿意在NT下玩无盘。

您还可以再写一个DHCP版本的，因为DHCP实在是更方便建立与维护。

对了，还有一点，bootp&tftp对机器无特殊要求，所以您也可以把WIN31，NW，LINUX下实现步骤作为advance篇加入，大全嘛，总要考虑进阶及特殊应用。比如NW引导DOS作2K终端，我敢说是个真玩家都乐意转入Etherboot的。

---

<div class="post-metadata">

作者： ![panhh](https://assets.netpcforum.org/letter_avatar_proxy/v4/letter/p/a9a28c/32.png) [@panhh](https://netpcforum.org/u/panhh)\
发布日期： [2002 年12 月 3 日 01:10 UTC](https://netpcforum.org/t/%E6%9C%AC%E4%BA%BA%E7%AC%AC%E4%B8%80%E6%AC%A1%E7%94%B5%E5%AD%90%E5%87%BA%E7%89%88%EF%BC%8C%E3%80%8Abootp%E8%BF%9C%E7%A8%8B%E5%90%AF%E5%8A%A8%E5%A4%A7%E5%85%A8%E3%80%8B/87688/34 "2002-12-03T01:10:29Z")

</div>

“大全”是有些夸大了，我对NW 基本没用过，所以没有提到。LINUX我是想另写一篇的。这一篇写的时间很紧，所以NT下也没有测试。多谢老兄提醒。

---

<div class="post-metadata">

作者： ![liang2000](https://assets.netpcforum.org/letter_avatar_proxy/v4/letter/l/ce73a5/32.png) [@liang2000](https://netpcforum.org/u/liang2000)\
发布日期： [2003 年2 月 21 日 05:20 UTC](https://netpcforum.org/t/%E6%9C%AC%E4%BA%BA%E7%AC%AC%E4%B8%80%E6%AC%A1%E7%94%B5%E5%AD%90%E5%87%BA%E7%89%88%EF%BC%8C%E3%80%8Abootp%E8%BF%9C%E7%A8%8B%E5%90%AF%E5%8A%A8%E5%A4%A7%E5%85%A8%E3%80%8B/87688/35 "2003-02-21T05:20:08Z")

</div>

在2000专业版上不可以正常使用bootpd32.exe。请问怎样才可以用呢？

---

<div class="post-metadata">

作者： ![panhh](https://assets.netpcforum.org/letter_avatar_proxy/v4/letter/p/a9a28c/32.png) [@panhh](https://netpcforum.org/u/panhh)\
发布日期： [2003 年2 月 21 日 05:33 UTC](https://netpcforum.org/t/%E6%9C%AC%E4%BA%BA%E7%AC%AC%E4%B8%80%E6%AC%A1%E7%94%B5%E5%AD%90%E5%87%BA%E7%89%88%EF%BC%8C%E3%80%8Abootp%E8%BF%9C%E7%A8%8B%E5%90%AF%E5%8A%A8%E5%A4%A7%E5%85%A8%E3%80%8B/87688/36 "2003-02-21T05:33:25Z")

</div>

专业版没试过，可能和98一样只能以命令行的形式运行吧，不能以服务的形式。  
专业版好象共享也有些问题，有连接数的限制吧。

---

<div class="post-metadata">

作者： ![liang2000](https://assets.netpcforum.org/letter_avatar_proxy/v4/letter/l/ce73a5/32.png) [@liang2000](https://netpcforum.org/u/liang2000)\
发布日期： [2003 年2 月 21 日 08:16 UTC](https://netpcforum.org/t/%E6%9C%AC%E4%BA%BA%E7%AC%AC%E4%B8%80%E6%AC%A1%E7%94%B5%E5%AD%90%E5%87%BA%E7%89%88%EF%BC%8C%E3%80%8Abootp%E8%BF%9C%E7%A8%8B%E5%90%AF%E5%8A%A8%E5%A4%A7%E5%85%A8%E3%80%8B/87688/37 "2003-02-21T08:16:54Z")

</div>

可以运行，但不可以象你的电子书那样正常运行。要不要设置其它什么呢？

---

<div class="post-metadata">

作者： ![疯子](https://assets.netpcforum.org/letter_avatar_proxy/v4/letter/%E7%96%AF/97f17d/32.png) [@疯子](https://netpcforum.org/u/%E7%96%AF%E5%AD%90)\
发布日期： [2003 年2 月 21 日 16:58 UTC](https://netpcforum.org/t/%E6%9C%AC%E4%BA%BA%E7%AC%AC%E4%B8%80%E6%AC%A1%E7%94%B5%E5%AD%90%E5%87%BA%E7%89%88%EF%BC%8C%E3%80%8Abootp%E8%BF%9C%E7%A8%8B%E5%90%AF%E5%8A%A8%E5%A4%A7%E5%85%A8%E3%80%8B/87688/38 "2003-02-21T16:58:46Z")

</div>

以前能做出NW的BOOTP，可对原理不太懂，今晚看了老大的问章，懂了很多，  
谢！！

---

<div class="post-metadata">

作者： ![ehaipai](https://assets.netpcforum.org/letter_avatar_proxy/v4/letter/e/ecae2f/32.png) [@ehaipai](https://netpcforum.org/u/ehaipai)\
发布日期： [2003 年2 月 22 日 02:01 UTC](https://netpcforum.org/t/%E6%9C%AC%E4%BA%BA%E7%AC%AC%E4%B8%80%E6%AC%A1%E7%94%B5%E5%AD%90%E5%87%BA%E7%89%88%EF%BC%8C%E3%80%8Abootp%E8%BF%9C%E7%A8%8B%E5%90%AF%E5%8A%A8%E5%A4%A7%E5%85%A8%E3%80%8B/87688/39 "2003-02-22T02:01:36Z")

</div>

得益非浅，感激直至！

---

<div class="post-metadata">

作者： ![xy777](https://assets.netpcforum.org/letter_avatar_proxy/v4/letter/x/ee7513/32.png) [@xy777](https://netpcforum.org/u/xy777)\
发布日期： [2003 年7 月 6 日 08:37 UTC](https://netpcforum.org/t/%E6%9C%AC%E4%BA%BA%E7%AC%AC%E4%B8%80%E6%AC%A1%E7%94%B5%E5%AD%90%E5%87%BA%E7%89%88%EF%BC%8C%E3%80%8Abootp%E8%BF%9C%E7%A8%8B%E5%90%AF%E5%8A%A8%E5%A4%A7%E5%85%A8%E3%80%8B/87688/40 "2003-07-06T08:37:40Z")

</div>

现在还能提供下载么?

[上一页](https://netpcforum.org/t/%E6%9C%AC%E4%BA%BA%E7%AC%AC%E4%B8%80%E6%AC%A1%E7%94%B5%E5%AD%90%E5%87%BA%E7%89%88%EF%BC%8C%E3%80%8Abootp%E8%BF%9C%E7%A8%8B%E5%90%AF%E5%8A%A8%E5%A4%A7%E5%85%A8%E3%80%8B/87688.md?page=1)

[下一页](https://netpcforum.org/t/%E6%9C%AC%E4%BA%BA%E7%AC%AC%E4%B8%80%E6%AC%A1%E7%94%B5%E5%AD%90%E5%87%BA%E7%89%88%EF%BC%8C%E3%80%8Abootp%E8%BF%9C%E7%A8%8B%E5%90%AF%E5%8A%A8%E5%A4%A7%E5%85%A8%E3%80%8B/87688.md?page=3)
