Network booting pixie (PXE)

First I will collect some links and categorize them as to how helpful of current as well as whether they work for my current configuration. The BIOS must support PXE (pixie ) network boot as a start. That condition has been met and so I will setup a server to respond to DHCP and deliver the system to boot. I wanted to use various versions of Linux and my own operating system in a convenient way. It also allows me to seamlessly upgrade all my machines at once. I have numerous machines and my own fake Internet that uses an ATM ( Asynchronous Transfer Mode ) link over a phone wire to my local server and router stack ( Which I will consider doing dual-stacking IPV4 and IPV6 as part of this investigation ). I will fill this in as I learn from the process. I will make some video snapshots from the server to the client at stages of its boot as well as wireshark traces of the process and detailed view for specific packets of interest. It is a pretest to implementing a TCP network boot on a remote station located x meters away.

Link 1 to Linux Journal article.
Link 2 to Ubuntu article.
Link 3 to another Linux Journal article
Link 4 Intel complete wireshark trace and explanation.

motey@motey-desktop:~$ aptitude search pxe
p kvm-pxe -PXE ROM's for KVM 
p ltsp    -cluster-xeconfig LTSP-Cluster symlink generator  
p pxe     -free PXE daemon

First of all, I must get the tools to do the work and install them. I could just follow somebody's script, but that can lead to an unstable system or even a reinstall and I don't want to do that on my server. I already have wireshark and camera capture installed and I won't get into that detail of explaining this.

As is shown in wireshark it starts with a DHCP request by the BIOS code of the machine that will receive the code to execute. As long as it meets certain criteria then it will execute and so I will probably build a little bit of ASM code and package it to serve as an indicator that it was received or to beep or echo back a packet to UDP for a separate local program to recognize an acknowledgement that it took over the machine successfully. I have traced a session without the server responding and then I will trace the process of a successful boot from network. Other methods to help understand the process is netstat and other general networking tools that I have discussed before.

sudo nmap 192.168.1.0-16

So it goes from BIOS to a DHCP PXE request with a UUID MAC address along with what it is requesting, which is a boot program. The command above is just to see who is who in the local zoo.

This image is an overview of the PXE protocol stages and how it starts with sending a CSMA packet on the LAN using DHCP and ends with the execution of the code provided by the Boot Server. I may enlist a few pythons or some C to simulate the other end of this to do some things that perhaps are not well known about machines in general, but might be fun to try out. One is a 386 program to identify the CPU and then a selected set of ASM instructions for that CPU, unless it is RISC, in which case I wonder how it identifies itself?

As is obvious the machine I am testing with is very dated and , well, if it blows up, there will be few tears on my part. However my neural circuits have become accustomed to its sensory impression and so it will be missed if it goes big batta boom.

The trace of a complete session is here at Intel,

To answer another question, IETF RFC 4578 and since Intel is the big cheese, X86 is ID zero. Included here for reference.

        Type   Architecture Name
            ----   -----------------
              0    Intel x86PC
              1    NEC/PC98
              2    EFI Itanium
              3    DEC Alpha
              4    Arc x86
              5    Intel Lean Client
              6    EFI IA32
              7    EFI BC
              8    EFI Xscale
              9    EFI x86-64

So since all of this is DHCP on UDP, I can use my UDP transceiver program written in C to interact with the remote machine.