PXE RPi3 boots stops

[jrburk]

I'm using isc-dhcp-server that responds to the PI:

TIME: 2018-02-04 18:44:04.141
IP: 192.168.1.80 (8:0:27:b1:5f:9b) > 192.168.1.12 (b8:27:eb:ac:1c:1)
OP: 2 (BOOTPREPLY)
HTYPE: 1 (Ethernet)
HLEN: 6
HOPS: 0
XID: 26f30339
SECS: 0
FLAGS: 0
CIADDR: 0.0.0.0
YIADDR: 192.168.1.12
SIADDR: 192.168.1.82
GIADDR: 0.0.0.0
CHADDR: b8:27:eb:ac:1c:01:00:00:00:00:00:00:00:00:00:00
SNAME: .
FNAME: pxelinux.0.
OPTION: 53 ( 1) DHCP message type 2 (DHCPOFFER)
OPTION: 54 ( 4) Server identifier 192.168.1.80
OPTION: 51 ( 4) IP address leasetime 86400 (24h)
OPTION: 43 ( 20) Vendor specific info 5261737062657272 Raspberr
7920506920426f6f y Pi Boo
74202020 t
OPTION: 66 ( 12) TFTP server name 192.168.1.82
OPTION: 1 ( 4) Subnet mask 255.255.255.0

Then on the tftpd-hpa server I'm seeing this:

Feb 4 18:44:05 content in.tftpd[1421]: RRQ from 192.168.1.12 filename bootcode.bin
Feb 4 18:44:05 content in.tftpd[1422]: RRQ from 192.168.1.12 filename bootsig.bin
Feb 4 18:44:05 content in.tftpd[1422]: sending NAK (1, File not found) to 192.168.1.12

Booting doesn't continue from here and the green LED blinks four times.

The Raspi touch display is black during the whole operation.

[ghollingworth]

tcpdump would probably help here:

Do 'ifconfig' to find out the interface name, usually 'eth0' but can be something else, then add to:

sudo tcpdump -i eth0 ether host b8:27:eb:ac:1c:01

This should show what is happening... I believe that tftpd-hpa should work, I've used it before, but it's possible something has been broken...

[jrburk]

It looks like the raspi is requesting more files (like autoboot.txt, config.txt, ...) but they don't appear in the tftp server log (see first post). Maybe the tftp client or server cannot recover from the missing bootsig.bin request.

Is there a place to obtain or generate the bootcode.sig to try without missing files?

indoor.txt

[ghollingworth]

It looks like tftp-hpd is failing, it might be worth trying to see if there is some kind of failure message ... One thing that is different in the first failing request is the addition of the tsize parameter.

I'd suggest trying a different tftp daemon to see if that's the only problem

[jrburk]

I tried with atftpd with the same result as with in.tftpd

[ghollingworth]

Can you get more information from the command line? Otherwise just run dnsmasq as a proxy only server and remove the other details... It will then provide you with a known working good tftp

Gordon

[jrburk]

I used the tftp command line client which works normal:

root@content:/tmp# tftp 192.168.1.82
tftp> get bootcode.bin
tftp> get bootsig.txt
Error code 1: File not found
tftp> get cmdline.txt
tftp> get start_x.elf
tftp> quit
root@content:/tmp# ls
bootcode.bin  bootsig.txt  cmdline.txt  start_x.elf

[ghollingworth]

Great, doesn't help though

[jrburk]

What kind of information can I provide that would help?

[6by9]

Sounds like exactly the issue I had with the boot stalling after getting bootcode.bin and checking for bootsig.bin.
Stick jsut bootcode.bin on an SD card and check with that.

[skspurling]

People have said they see the TFTP server stall after the bootsig.bin file. Mine appears like the Pi won't proceed without the bootsig.bin. I am running a Pi 3B+. Would that make things work any differently?

[weinholt]

Here's tcpdump -e output showing what the problem is:

14:37:03.557737 b8:27:eb:6f:3d:3c (oui Unknown) > d4:3d:7e:6b:6d:74 (oui Unknown), ethertype IPv4 (0x0800), length 62: 192.168.1.124.49152 > upshot.tftp:  20 RRQ "bootsig.bin" octet
14:37:03.560759 d4:3d:7e:6b:6d:74 (oui Unknown) > b8:27:eb:6f:3d:3c (oui Unknown), ethertype IPv4 (0x0800), length 61: upshot.60968 > 192.168.1.124.49152: UDP, length 19
14:37:05.672278 b8:27:eb:6f:3d:3c (oui Unknown) > aa:aa:aa:aa:aa:aa (oui Unknown), ethertype IPv4 (0x0800), length 71: 192.168.1.124.49154 > upshot.tftp:  29 RRQ "autoboot.txt" octet tsize 0

After the request for bootsig.bin the following requests all have the Ethernet destination address set to aa:aa:aa:aa:aa:aa. A simple workaround is to add that address to your server (although I only tested it with br0, not eth0, and I can't promise that this will not mess anything else up for you):

ip link add link eth0 address aa:aa:aa:aa:aa:aa eth0.1 type macvlan
ip link set eth0.1 up

I checked that this works with Linux 4.17 and both dnsmasq and tftpd-hpa.

[Flole998]

What does wireshark show on the Pi's NIC? The Server is on the same subnet, is that correct?