Hi Ross, > Ok, try adding -vv to the tftpd options and look in the messages to > see if an exact error is reported. Tried but with no success. Updated /etc/xinetd.d/tftp as follows: [root at chl1 ~]# cat /etc/xinetd.d/tftp # default: off # description: The tftp server serves files using the trivial file transfer \ # protocol. The tftp protocol is often used to boot diskless \ # workstations, download configuration files to network-aware printers, \ # and to start the installation process for some operating systems. service tftp { disable = no socket_type = dgram protocol = udp wait = no user = root server = /usr/sbin/in.tftpd server_args = -c -s -vv /tftpboot per_source = 11 cps = 100 2 flags = IPv4 } [root at chl1 ~]# Then rebooted. After reboot the tftpd is not running (even if enabled, isn't it strange?!?!?) [root at chl1 ~]# ps -ef | grep tftp root 2896 2814 0 00:28 pts/2 00:00:00 grep tftp [root at chl1 ~]# Just when I issue the tftp command at the client side: LabTI-Infra-3524XL-01#copy running-config tftp: Address or name of remote host []? 10.58.2.204 Destination filename [labti-infra-3524xl-01-confg]? TFTP: error code 1 received - File not found %Error opening tftp://10.58.2.204/labti-infra-3524xl-01-confg (Undefined error) LabTI-Infra-3524XL-01# I se that the tftp process is started: [root at chl1 ~]# ps -ef | grep tftp root 2904 2307 0 00:28 ? 00:00:00 in.tftpd -s /tftpboot root 2914 2814 0 00:28 pts/2 00:00:00 grep tftp [root at chl1 ~]# and in /var/log/messages I see: Sep 14 00:28:40 chl1 xinetd[2307]: START: tftp pid=2904 from=10.58.2.159 Sep 14 00:28:41 chl1 kernel: usb 2-1: reset low speed USB device using uhci_hcd and address 3 [root at chl1 ~]# So, xinetd is start tftpd ON-DEMAND (?!?!?!?) *and*, worst thing, apparenty not reading from /etc/xinetd.d/tftp. Any idea??? Thanks again, Davide On Sep 13, 2007, at 11:59 PM, Ross S. W. Walker wrote: > Davide Grandis wrote: >> >> Hi Les, Ross, all >> >> Thanks to all who responded - btw, the issue is still open. >> >> Concerning: >> >>>> The usual approach is to create the filename yourself (ssh in >>>> and "touch >>>> devicename-confg") and chmod it to 666 before doing the tftp. >>>> That way >>>> you don't have to let tftp create any files and its lack of >>>> authentication is less of an issue). If you are committing >>>> the configs >>>> to cvs (a good idea, since you can easily track changes), >>>> note that cvs >>>> for some reason will change the modes as a side effect of the >>>> commit and >>>> you'll have to put them back to 666 before the next tftp in. >>> >>> Yes, those are good controls on tftp and sound like best practices. >>> >>> For initial population of /tftpboot though one may want to use -c >>> and then once it is populated remove the -c switch, check it all >>> into cvs/subversion and make sure the permissions are sane. >> >> Let me tell that in some circumstances it could be not that easy >> create the file in advance. This is usually the case when >> TFTP-ing in >> from a network device that has limited capabilities (no SSH client >> tipically). Anyway, that's an added complexity that is unncesserary >> in my point of view. >> > > Ok, try adding -vv to the tftpd options and look in the messages to > see if an exact error is reported. > > > >> On Sep 13, 2007, at 9:33 PM, Ross S. W. Walker wrote: >> >>> Les Mikesell wrote: >>>> >>>> Ross S. W. Walker wrote: >>>> >>>>>>> Just to make sure, is the /tftpboot directory set to perms 777? >>>>>> Not that that parent directory (/tftpboot) requires (or should >>>>>> ever have) anything like that to work >>>>>> >>>>>> -- why the voodoo suggestion? >>>>> >>>>> Because if you are allowing any old anonymous user to write to >>>>> that directory then why would one care if you only allowed group >>>>> 'nobody' to write there? >>>>> >>>>> You could set it to 755 and create a 'cisco' dir underneath with >>>>> 777, but I would leave that for when it's working. >>>>> >>>>> Chances are though everything under /tftpboot is subject to >>>>> modification and /tftpboot will need to be a separate volume to >>>>> protect against DoS through filling up the disk drive. >>>> >>>> The usual approach is to create the filename yourself (ssh in >>>> and "touch >>>> devicename-confg") and chmod it to 666 before doing the tftp. >>>> That way >>>> you don't have to let tftp create any files and its lack of >>>> authentication is less of an issue). If you are committing >>>> the configs >>>> to cvs (a good idea, since you can easily track changes), >>>> note that cvs >>>> for some reason will change the modes as a side effect of the >>>> commit and >>>> you'll have to put them back to 666 before the next tftp in. >>> >>> Yes, those are good controls on tftp and sound like best practices. >>> >>> For initial population of /tftpboot though one may want to use -c >>> and then once it is populated remove the -c switch, check it all >>> into cvs/subversion and make sure the permissions are sane. >>> >>> -Ross >>> >>> >> _____________________________________________________________________ >> _ >>> This e-mail, and any attachments thereto, is intended only >> for use by >>> the addressee(s) named herein and may contain legally privileged >>> and/or confidential information. If you are not the >> intended recipient >>> of this e-mail, you are hereby notified that any dissemination, >>> distribution or copying of this e-mail, and any attachments thereto, >>> is strictly prohibited. If you have received this e-mail in error, >>> please immediately notify the sender and permanently delete the >>> original and any copy or printout thereof. >>> >>> _______________________________________________ >>> CentOS mailing list >>> CentOS at centos.org >>> http://lists.centos.org/mailman/listinfo/centos >> > > ______________________________________________________________________ > This e-mail, and any attachments thereto, is intended only for use by > the addressee(s) named herein and may contain legally privileged > and/or confidential information. If you are not the intended recipient > of this e-mail, you are hereby notified that any dissemination, > distribution or copying of this e-mail, and any attachments thereto, > is strictly prohibited. If you have received this e-mail in error, > please immediately notify the sender and permanently delete the > original and any copy or printout thereof. >