ftp://ftp.mamalinux.com/pub/atftp/
-Unfortunately, the Intel LANDesk Service Agent II prior to version
-0.99h (PXE PDK V2.4) seems to have a host of serious bugs. Among
-other things, it requests the TFTP "blksize" option, but will be
-mortally confused if this option is actually accepted by the server!
-There are three possible workarounds for this bug:
-
-1. Use a TFTP server with doesn't support "blksize".
-
- Unfortunately, PXELINUX requires the "tsize" option to be
- supported, and it is very unusual for TFTP servers to implement one
- and not the other. Both the tftp-hpa and atftp TFTP servers (see
- above) therefore can be configured to disable the blksize option.
- Use "-r blksize" for tftp-hpa, "--no-blksize" for atftp.
-
-2. Use MTFTP for the initial bootstrap. You need an MTFTP server with
- the appropriate DHCP setup to do this.
-
-3. Use appropriate DHCP options that the client will attempt MTFTP
- before trying conventional TFTP. It seems that the client will not
- request the "blksize" option if it has tried MTFTP and failed.
- These DHCP options are beyond the scope of this document.
-
-These systems also seem to break if PMTU discovery is enabled on the
-TFTP server. This has to be disabled in the kernel on the TFTP
-server. On Linux, you can disable PMTU discovery by setting:
-
- echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc
-
-Note that this may cause bad performance for other services on the machine.
-
++++ SETTING UP THE DHCP SERVER ++++
This allows an unattended machine to recover in case it had bad enough
luck of trying to boot at the same time the TFTP server goes down.
+Lots of PXE stacks, especially old ones, have various problems of
+varying degrees of severity. Please see:
+
+ http://syslinux.zytor.com/hardware.php
+
+... for a list of currently known hardware problems, with workarounds
+if known.
+
++++ CURRENTLY KNOWN PROBLEMS ++++
decent way of telling it to free up all memory and unchain any
interrupts; it allows the base stack to be unloaded, but not the
UNDI driver.
-+ There seems to be a problem with sending ACK "storms"; a number of
- ACK packets fired off without the proper delay in between. I
- suspect this is a PXE firmware problem, rather than a PXELINUX
- problem.
+ We should probably call the UDP receive function in the keyboard
entry loop, so that we answer ARP requests.
-+ Boot sectors don't work yet... they probably need auxilliary information
- (such as device) to work at all.
++ Boot sectors/disk images are not supported yet.
If you have additional problems, please contact the SYSLINUX mailing
list (see syslinux.doc for the address.)