I figured out that, in at least some cases, pkg_add through ftp was hanging because some network equipment somewhere on the path was not listening closely enough: it's quite easy to decorrelate the control connection from the data connection.
Some crappy equipments, some moronic sysadmins, or some cheap nats with too many machines plugged into a single public IP can be the source of the problem (basically, ftp is too complex for the new age of plug and play admins... it's a very good indicator of how good your admins are, actually): they don't see anything over the control connection, and they drop it after a few minutes of inactivity (just five, in a case I saw !). So, ftp now supports a -k option, that will send some bytes (innocuous noop commands) over the control connection during a large transfer), so that you don't get disconnected. This doesn't solve the other ftp problem, that in many cases you may have an intermediate proxy that does not understand telnet correctly, and so your urgent ABORTs won't get through correctly, and it will take forever for pkg_add to close connections early (we solved this in our ftp-proxy a few years ago). So, from pkg_add, you can try out to set the env variable FTP_KEEPALIVE if you think you have the problem... one common symptom is to have the installation of openoffice hanging at the end... This requires fully current source, of course... The changes should dribble to a binary snapshot at some point.
