7 Replies Latest reply: Dec 14, 2012 11:30 AM by John Lockwood
tim_r_66 Level 1 Level 1 (45 points)

I am experimenting with net booting of some Wyse Winterm, model SX0 (product S90), terminals.  These terminals are pretty old and appear to be using Intel UNDI, PXE-2.0 (build 082).


My server is a recently built MacMini (2010) with OS X 10.8.2 and Server 2.2.  DHCP is running on the server and the /etc/bootpd.plist has been modified to include options 66 and 67 data built using John Lockwood's DHCP Option Code Utility with the first eight characters deleted as described in this thread.  With all this running, I power on the Wyse terminal which successfully pulls up the dhcp server and gateway addresses, and is assigned an ip address (which OS X Server also reports).


However, when the client reaches out with tftp, access violations (PXE-T02, PXE-E3C) are reported.  I have checked and rechecked the permissions in the tftpd working directory are set to 777 and that parent directory is 755 (owner/group is root/wheel).  Here is the tftp.plist:


<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">


FWIW, I'm trying to load pxelinux.0 and have set the permissions on that file to 777 and changed the owner/grp to root/wheel, but the same errors occur on the client's boot.  Same result when I changed the permissions/owner/group for the other associated files. 


On what may be a related note, I added the -d and -l options for tftpd but nothing is showing up in syslog.  I'm clueless as to why.


Are there any recommendations on what I should try next?


Thank you in advance!



Mac mini, OS X Server
  • John Lockwood Level 5 Level 5 (6,700 points)

    Can you try testing it from another Mac instead of the Wyse? This may let you see more information and try more options.


    On the client Mac you would try something like


    tftp serveraddress

    get filename


    You could also try the full path name


    get /private/tftpboot/filename


    UPDATE: found the following which may help.



  • tim_r_66 Level 1 Level 1 (45 points)

    Thanks John.  I have tested using tftp from the local server (but not to localhost) and it works, but I'll try tonight to connect another Mac. 


    And I'll definitely work through the link.



  • tim_r_66 Level 1 Level 1 (45 points)

    Quick update.


    I used netstat and confirmed tftp is running.  I also connected another Mac (iMac) and connected to the tftpd.  A simple "get pxelinux.0" succeeded.


    I am still a little baffled that none of this is getting logged in the system.log; only TftpServer's (the gui for configuring tftpd) load and unload of the tftpd is being logged.


    When I get back later tonight I'll look at trying to rewrite the plist in case something is corrupt. 


    As always, I welcome more thoughts.






    p.s., I should not need to have NetInstall service running or configured in any specific way, right?

  • tim_r_66 Level 1 Level 1 (45 points)

    I decided to slick the server and start fresh, this time right off with Mountain Lion vice SLS->ML.  This setup does seem cleaner.


    I configured DNS, OD, DHCP and then NetInstall.  Created some ML and L images and tested NetBoot of those images using a macbook and an older macmini.  Both worked well.


    I then tested tftp to see if it was running; it is, and a simple get from the local server works fine.


    Next I went back to test the Wyse terminal.  I added a /etc/bootptab and assigned a static ip for the thin client and the boot name of pxelinux.0.  I also used John Lockwood's utility to calculate the option 66 and option 67 values, and then added them to the /etc/bootpd.plist.  Trying to boot the client is now giving a file not found error.  Tonight when I have more time I'll check file permissions.


    John:  I also wanted to ask if you would check the option 67 result for me.  I used your utility (code 67, type string) on "pxelinux.0" (without the quotes) and it returns:




    Using this discussion, I understand I am to delete the leading eight characters for ML, which I have done.  What I did not see conclusively was if the trailing "o=" should be changed to "==", thus making "pxelinux.0" --> "cHhlbGludXguMA=="? And if so, is this also the case with option 66?


    Thanks in advance.   



  • John Lockwood Level 5 Level 5 (6,700 points)

    Apple store the data values in their /etc/bootpd.plist file in base64 encoded format. Base64 pads out data to certain lengths, so in this case it should in theory have == at the end to pad it out. However depending on what the encoded value will result in, the last two character might well be something else not necessarily o=.


    To help confirm what it should be you can either as some have use a commandline utility in Terminal.app to encode to Base64, e.g. echo -n "encode me" | openssl enc -base64, or use one of the many online website encoders.


    Note: if you don't use the -n option with echo it adds a carriage return to the string.


    I have just used the following to help confirm what pxelinux.0 should end up as




    It happens to agree with my utility (at least when run in Snow Leopard) as you will see.


    To make matter a little more difficult, I seem to recall that in some cases DHCP option code strings need to have a null character (hex 00) as a string terminator, this is in programming speak referred to as a null-terminated string. It would be possible to generate this using my utility but you have to do it a different way, you would take the string, convert it to hexadecimal, use the hexadecimal option in my utility and add 00 at the end.

  • tim_r_66 Level 1 Level 1 (45 points)

    Eureka!  I won't bore everyone with details but after checking, double checking encoded strings, file permissions, etc., I was about to give up when I decided to try adding the null to teh end of the boot filename string. 


    John, you rock.  Thanks a bunch.



  • John Lockwood Level 5 Level 5 (6,700 points)

    At some point I will issue an updated version of my utility with a fix for running under Mountain Lion. I will also add a choice for null-terminated strings.


    The main delay will be finding a free suitable webhosting service, I used to use MobileMe.