The "Error: file transfer stalled" often happens when the sensor is unable to download the file within the time allowed.
This can happen
A) if the network is really busy (you might try during a quieter time like at night or the weekend).
B) if the scp server is really busy (try when the scp server is less busy or try another scp server)
C) if the connection between the sensor and scp server is really slow, like the scp server having to be reached over the internet (try a scp server on the same local subnet as the sensor instead)
The sensor has a hardset timeout value in which the scp transfer must take place (I think it is 5 minutes).
If scp does not work for you, have you considered using Http, Https, or ftp instead.
The ftp timeout can be configured (unlike scp) so if you see long ftp times then increase the ftp timeout to accomodate the slower transfer.
NOTE:
Until the file is either transferred and installed or the timeout is reached, the sensor will not respond to other commands.
In the case of 4.1(4g) patch we are seeing long install times.
I saw that one of your original statements was that your http install "hung".
It is possible that the install was actually still in progress, but worse yet by powering off and on the sensor you may have corrupted the sensor as it was in the middle of updating files.
Never power off and on a sensor in the middle of an upgrade unless you are positive it is "hung".
And then if you do, then go ahead and do a re-install of the base image in order to erase any files that may have been corrupted.
How can you to tell if it is "hung". Always have a "service" account created on the sensor. If you think it might be "hung" then login with the "service" account. Execute "ps -e fw" to see what processes are running. If you see the package intaller still running, then let it keep going.
With 4.1(4g) patch we are hearing update times as long as 50 minutes to an hour on smaller platforms like the 4210 and 4215.
Why so long?
The sensor creates what are known as cache files for the regular expressions. All of the regular expressions for a particular engine are compiled together into what is in effect one large regular expression known as the cache file.
Ordinarily a sigupdate will require creation of new cache files when new signatures are added for an engine. Generally new signatures are only added for one or 2 engines during an update so only 1 or 2 cache files have to be regenerated.
BUT with 4.1(4g) the cache file mechanism has changed. So with the installation of 4.1(4)g ALL of the cache files are deleted and have to be regenerated. This can take quite awhile on the lower end systems.
What is being done to address this.
With version 5.0 (being released this month), the sensor will no longer need to generate cache files for signature updates. We will be delivering the cache files inside the signature update package so the sensor will not have to regenerate them.
This will greatly reduce the installation time of the updates (you could still have download time issues though)
The only time the sensor will have to generate cache files is if the user adds custom signatures or decides to UnRetire a Cisco signature (Retired Cisco signatures are not included in the cache files delivered in the signature updates). So creating custom signatures and unretiring signatures coudl still take some time.
