12-18-2001 04:13 AM - edited 03-08-2019 09:25 PM
I am trying to upgrade the Activation keys on PIX 515 V6.1
To do this I am trying to upgrade the image via the tftp from monitor.
I have set addr/file/gate/server etc
When I try the tftp the tftp server sees the attempts but fails to send any bytes; retrying and eventually aborting
The PIX reports the usual lines of dots .........so it is 'trying' to upgrade.
Strangely if the pix is rebooted to a full running version; I am able to upgrade it SUCCESFULLY using copy tftp and the same tftp server/files etc
(but this does not allow the new activation key to be entered!!)
Any ideas please?
12-18-2001 05:42 AM
I would suggest:
1) when in rommon mode, ensure that you can ping the tftp server from the pix
2) check the duplex settings on the pix /try connecting from a different host (i.e. another laptop) some laptops have a problem autonegotiating the duplex settings
3) try a different tftp server (despite the fact that it works when you're not in rommon mode).
HTH
Jeff
01-10-2002 01:55 AM
I have the same problem.
I followed your suggestions but I receive always this error from the PIX:
TFTP failed (return:-12 arg:0x0)
I haven't find this error in the table of TFTP Error Code Numeric Values.
How can I resolve thi issue?
Thanks
Lorenzo
01-10-2002 01:54 PM
I have had similar problems when I used any other TFTP server than the Cisco provided one. Which TFTP server are you using?
01-11-2002 09:33 AM
I have tried both with Cisco TFTP server both with others like 3COM...
Every time that tries again the download gets worse.
What do you suggest me to do?
Thanks
Lorenzo
01-11-2002 12:02 PM
I have had this problem on V6 also. The only way I have been sucessfull is to use a cross over cable pulled directly into one of the ethernet ports on the pix and then use a define and ip for the pix with the tftp server being the next ip (i.e 192.168.0.1 and 192.168.0.2 where if 192.168.0.2 is the tftp server i also define the gateway as the same address as the tftp server. It all works then, while I agree this should not be the way to do it. It works everytime this way.
01-11-2002 01:01 PM
Most likely what is happening is the device that the PIX is plugged into is hard-coded for the speed and duplex. The problem with this is when the PIX is in monitor mode, it will only autonegotiate the speed/duplex. Thus, if the other end is hard-coded for Full duplex, the PIX will end up in Half-Duplex (because the other side won't negotiate) and you will have a duplex mismatch. This will cause packets to drop and TFTP won't recover.
This is probably why the cross-over cable suggestion previously worked.
Try hard-coding the other side to half duplex or just plug a PC directly into the PIX with a crossover cable so both devices will autonegotiate.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide