tftp upgrade failure from monitor prompt on pix515

[dave.thornton]

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?

[jekrauss]

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

[Lorenzo de Letteriis]

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

[geoffry]

I have had similar problems when I used any other TFTP server than the Cisco provided one. Which TFTP server are you using?

[Lorenzo de Letteriis]

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

[pmay01]

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.

[jekrauss]

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.