Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

User profile for user: tim_r_66
tim_r_66 Author
User level: Level 1
51 points

PXE/tftp Access Violation Errors

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">
<dict>
          <key>Disabled</key>
          <true/>
          <key>InitGroups</key>
          <true/>
          <key>Label</key>
          <string>com.apple.tftpd</string>
          <key>ProgramArguments</key>
          <array>
                    <string>/usr/libexec/tftpd</string>
                    <string>-d</string>
                <string>-l</string>
                    <string>-s</string>
                    <string>/private/tftpboot</string>
          </array>
          <key>Sockets</key>
          <dict>
                    <key>Listeners</key>
                    <dict>
                              <key>SockServiceName</key>
                              <string>tftp</string>
                              <key>SockType</key>
                              <string>dgram</string>
                    </dict>
          </dict>
          <key>inetdCompatibility</key>
          <dict>
                    <key>Wait</key>
                    <true/>
          </dict>
</dict>
</plist>


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!


Tim

Mac mini, OS X Server

Posted on Dec 10, 2012 4:26 AM

Reply
7 replies
User profile for user: John Lockwood
John Lockwood
User level: Level 6
13,679 points

Dec 10, 2012 5:11 AM in response to tim_r_66

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.


http://seanism.com/blog/2012/04/tftp-in-os-x-lion-10-7/

Reply
User profile for user: tim_r_66
tim_r_66 Author
User level: Level 1
51 points

Dec 10, 2012 4:11 PM in response to John Lockwood

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.


Thanks!


Tim


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

Reply
User profile for user: tim_r_66
tim_r_66 Author
User level: Level 1
51 points

Dec 13, 2012 7:00 AM in response to John Lockwood

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:


<key>dhcp_option_67</key>
<data>
LW4gLWUgcHhlbGludXguMAo=
</data>


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.


Tim

Reply
User profile for user: John Lockwood
John Lockwood
User level: Level 6
13,679 points

Dec 13, 2012 11:02 AM in response to tim_r_66

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


http://www.motobit.com/util/base64-decoder-encoder.asp


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.

Reply

PXE/tftp Access Violation Errors

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.
Learn more Sign up