# PXE/TFTP Booting Problems

## Kenji Miyamoto

I'm trying to boot a device into OpenBSD using PXE and a TFTP server running Gentoo, but I'm having problems with it.  It is able to get a file called "pxeboot" via TFTP, but it can't get the "bsd" image.  Here's the output from the serial terminal:

```
Intel UNDI, PXE-2.0 (build 082)

Copyright (C) 1997,1998,1999  Intel Corporation

VIA Rhine III Management Adapter v2.43 (2005/12/15)

CLIENT MAC ADDR: 00 00 24 CC 99 F4

CLIENT IP: 192.168.0.195  MASK: 255.255.255.0  DHCP IP: 192.168.0.1

GATEWAY IP: 192.168.0.1

probing: pc0 com0 com1 pci pxe![2.1] mem[639K 511M a20=on]

disk:

net: mac 00:00:24:cc:99:f4, ip 192.168.0.195, server 0.0.0.0

>> OpenBSD/i386 PXEBOOT 2.03

open(tftp:/etc/boot.conf): Unknown error: code 60

boot> bsd

booting tftp:bsd: open tftp:bsd: Unknown error: code 60

 failed(60). will try /bsd

boot>

boot> help

commands: # boot echo env help ls machine reboot set stty time

machine: boot diskinfo memory

boot> ls

stat(tftp:/.): Unknown error: code 60

boot>
```

/etc/xinet.d/tftp-stream:

```
service tftp

{

        disable         = no

        id              = tftp

        wait            = no

        socket_type     = stream

        user            = nobody

        group           = nobody

        server          = /usr/sbin/in.tftpd

        server_args     = /tftpboot

        log_on_success  = PID HOST USERID EXIT DURATION

        log_on_failure  = USERID ATTEMPT

}
```

/etc/xinet.d/tftp-dgram:

```
service tftp

{

        disable         = no

        id              = tftp

        wait            = yes

        socket_type     = dgram

        user            = nobody

        group           = nobody

        server          = /usr/sbin/in.tftpd

        server_args     = /tftpboot

        log_on_success  = PID HOST USERID EXIT DURATION

        log_on_failure  = USERID ATTEMPT

}
```

The contents of /tftpboot:

```
lrwxrwxrwx 1 nobody nobody       6 2010-01-19 08:03 bsd -> bsd.rd

-rw-r--r-- 1 nobody nobody 6059175 2009-07-10 14:03 bsd.rd

-rw-r--r-- 1 nobody nobody   53532 2009-07-10 14:03 pxeboot
```

/tftpboot itself:

```
drwxr-xr-x 2 nobody nobody 120 2010-01-19 08:03 /tftpboot
```

While I do have a firewall, no packets were dropped during the boot.

Also, I tried using the tftp command on another machine:

```
tftp> get pxeboot

Transfer timed out.
```

What have I done incorrectly here?

----------

## Hu

Given that the OpenBSD PXEBOOT client appears to have loaded successfully, the environment must be at least partially functional.  The permissions look like they should work, though I suggest making the files and directory be owned by root:root so that processes running as nobody cannot modify the TFTP environment.  Try using tcpdump to monitor the startup and check for any errors sent over the network when the first failure is printed on the netboot client.  Also, you may want to strace the tftp server to check that it is not getting any unexpected system call errors.

----------

## Kenji Miyamoto

Here's what happens when I try to fetch 'bsd' from the OpenBSD PXE bootloader:

```
19:43:52.786054 IP 192.168.0.195.2966 > 0.0.0.0.tftp:  12 RRQ "bsd" octet

19:43:53.996328 IP 192.168.0.195.2966 > 0.0.0.0.tftp:  12 RRQ "bsd" octet

19:43:57.997768 IP 192.168.0.195.2966 > 0.0.0.0.tftp:  12 RRQ "bsd" octet

19:44:05.995587 IP 192.168.0.195.2966 > 0.0.0.0.tftp:  12 RRQ "bsd" octet
```

This is what happens when I fetch 'bsd' from a regular tftp program on another machine:

```
19:45:21.134704 IP 192.168.0.2.41500 > 192.168.0.1.tftp:  15 RRQ "bsd" netascii
```

It looks like the bootloader only tries to fetch it from 0.0.0.0, and since xinetd doesn't respond to it xinetd must be bound to 192.168.0.1.

How do I tell xinetd to listen on 0.0.0.0?  Having the line "bind = 0.0.0.0" doesn't work.

----------

## Kenji Miyamoto

Nevermind.  The solution was to add a "next-server" line to my dhcpd.conf.

What do the -l and -s options to for tftpd?  I've seen them, but the always cause tftpd to stop serving files.

----------

## Hu

I meant for you to examine the traffic in detail using Wireshark or a more detailed tcpdump output, but it seems you found the solution another way.

 *Kenji Miyamoto wrote:*   

> What do the -l and -s options to for tftpd?  I've seen them, but the always cause tftpd to stop serving files.

 From man in.tftpd: *man in.tftpd wrote:*   

>        -l, --listen
> 
>               Run the server in standalone (listen) mode, rather than run from
> 
>               inetd.  In listen mode, the --timeout option is ignored, and the
> ...

 Using -l would cause the server to run in listen mode, rather than assuming that xinetd handled the listening part.  You would need to have in.tftpd started independently and left running to make use of -l.  Using -s causes a chroot call, which affects the effective paths of all files served.  Thus, clients need to format their requests differently for a server with --secure versus one without it.

----------

