The Dreaded TFTP error 2 (Access Violation)

[Craig White]

On Fri, 2002-12-20 at 16:40, George Gambill wrote:
> 
> 
> /var/log/messages =
> Dec 20 15:54:09 nowhere dhcpd: DHCPDISCOVER from 00:04:5a:82:b6:5d via eth0
> Dec 20 15:54:09 nowhere dhcpd: DHCPOFFER on 192.168.100.151 via eth0
> Dec 20 15:54:09 nowhere dhcpd: DHCPREQUETS for 192.160.100.151
> (192.168.100.66) from 00:04:5a:82:b6:5d via eth0
> Dec 20 15:54:09 nowhere dhcpd: DHCPPACK on 192.168.100.151 to
> 00:04:5a:82:b6:5d via eth0
> 
> These 4 lines repeat about every 4 seconds (till I kill the client) which is
> the cycle time for the Client to retry.
-----
If it can sucessfully lease an ip address...you are dead in the water. I
believe that DHCPACK means that it is leased but to double check...
less /var/lib/dhcp/dhcpd.leases or use webmin to check leased addresses
to confirm that you do have an address AND that it is is indeed
192.168.100.151 (I am presuming that the typos above are because you
typed this and not because you actually copied and pasted this info.
-----
> 
> Notice, in the /etc/dhcpd.conf file the mac address is in all upper case.
> But it seems to work.
> 
> /var/log/security =
> Dec 20 15:54:09 nowhere xinetd[621]: START: tftp pid=902
> from=192.168.100.151
> 
> This line also repeats at the same time periods as does /var/log/message but
> with a different pid.
> 
-----
This tells me that you got an ip address leased and that it indeed
communicated with the tftp server.

last|less should show when the connection was made (if it was made) to
the tftp server - my guess is that it will show up there.
-----
> 
> >if you aren't going to use dns...is /etc/nsswitch.conf gonna allow that?
> 
> >hosts:	files nisplus dns
> 
> Good thought, that line now reads "#hosts:	files nisplus dns" (no
> quotes)
-----
the '#' means that it is commented out and not active...the line s/b
hosts		files nisplus dns
-----
> 
> One more thing I hate to mention but should.  I have come to understand that
> RH8 brings tftp with it.  I didn't know that and didn't see it.  Therefore,
> I downloaded a internet copy and installed (I think) it with tar.  I am
> wondering if that haste may have done bad things.  I am tempted to reformat
> the HD and reinstall knowing what I know now.  Got no problem with that.
> What do you thing???
> 
-----
can't see how 'reformat' / reinstall is gonna fix this.

it shouldn't matter whether tftp was installed via tarball or redhat rpm
UNLESS (and this may be significant) it was distributed as a binary and
compiled with an unsupported compiler.

'which tftpd'
should tell you where it is and you can simply delete it and then
install redhat's either from cd or using up2date if you wish. If you do
this, you will probably want to remove /etc/xinetd/tftpd before you
install the redhat rpm (and of course, edit the new file - disable =
no).

Seems as though this is where your problem is...

make sure that 'everyone' has read access to /tftpboot and any files
contained therein...

ls -l /
ls -l /tftpboot

-rw-r--r--
       ^     this is the important bit for tftpboot - I have to believe
that because the nature of tftp is anonymous, this would be essential.
'chmod' o+r /tftpboot -R
should take care of any permission issues

I have no experience whatsoever with ltsp but I have to believe that
they run mail lists which might give you better answers.

I do believe that you are getting close. Rebooting is a Windows solution
and doesn't generally fix things on linux. You can 'kill' a process and
restart it...you can 'stop' a service and restart it (necessary for most
daemons when you change the configuration...e.g., service network
restart, service xinetd restart (tftpd undoubted runs under xinetd)

Craig