FTP transfer through Kermit

[Phillip Popp]

Hi all,
Does any one have solid experience with fTP transfer. I a using Kermit. It has worked great for years with no problmes. I am using a script to push data from an overseas server to my server here in America. I have lost my ability to transfer any files from to to this server overseas. I am running HP 10.2. The transfer just stops dead, no data gets transfered, and the script hangs up. I added .log files that Kermit supports, but I be dammed if I can read it, can any one help? I attached the log files. Here is the kicker! I do not control the file wall between America and overseas, that is controled by a different group with in my company, they assure me they have not changed a thing with FTP settings. Also this an innetwork transfer, we do it over secure lines.

I am at a loss on how to trouble shoot htis issue, so at least I can go back to fire wall people and say here look, this is what is happining.

I really need some solid help here.

Thanks,

Phil

[Tim Nelson]

None of this may help and I am digging this from way back in the memory banks.

1st) kermit is not FTP. Kermit was developed in the days of serial and/or modem connections, you connected or dialed up, started the kermit server on the host then executed a put or get using ZMODEM, YMODEM or other protocal types

2nd) I cannot ascertain any errors from the attached debug either.

Some items to research.
-If you are successfully connecting then phase1 of connectivity and access is good.
-Is there even a partial file on the destination ? If so there would no reason to believe this is FW related.
-Can you GET a file ?
-Other possibilities, full destination, permission issues on destination, test some basic commands ( google "kermit" to see if there are some basic troubleshooting you can use )

In the end.. Convert to FTP as it is the current up to date convention for transfering files via the network.

[Phillip Popp]

Hi Nelson,
Yes Kermit is way back but it is still active at Berkly where they developed it I believe. It is a sold communication tool. Any way, No data what so ever gets transferred. Permissions are all the same nothing has changed. I can not GET any files either. Not even through Filezilla.

Any suggestions what to use for FTP with in a hp unxi enviroment?

Thanks

phil

[Matti_Kurkela · Accepted solution]

(Phillip, please use the "Reply" function instead of "Start new thread" when giving more information about your original question.)

Tim, a modern C-Kermit program *does* contain a FTP support module. It is sometimes used instead of standard FTP program because the Kermit program offers much better tools for automating the file transfers.
http://www.columbia.edu/kermit/ck80.html

The log file attached here looks like Kermit's internal debug log, which is probably not very useful for network-level troubleshooting.

Your other message
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1169596
contained a different log, which seem to contain one line per connection.

These two consecutive lines seem particularly interesting:
20061205 04:00:32 guest0005 10223 T=FTP N=aa.aaa.aaa.aa H=ucomserv E=00:00:12
20071002 23:05:12 anadigics 23284 T=FTP N=bbb.bbb.bb.bb H=ucomserv E=00:02:22

(IP addresses covered up, just in case...)

If the number at the beginning is a datestamp (as it looks like), there seems to have been a long break in data transfers between 5th of December 2006 and 2nd of October 2007. During that break, two things seem to have changed. First, "guest0005" has become "anadigics": is this a server name, or a user name?
Second, the IP address shown in the logs has changed.
Are these changes as they should be?

Could you try to test the connection with a normal FTP client (such as the "ftp" command in the HP-UX)?
Things to check:
- do you get the login message from the FTP server?
- can you log in? (i.e. is the username/password combination valid?)
- if you can log in, can you get a listing of the remote server's directory? (The directory listing causes FTP to open a second TCP/IP connection, just like a file transfer does. This connection does not necessarily use standard port numbers, so it's not so easy to allow through firewalls.)

You might need some information about what happens at the network level when a connection is attempted. If there are no useful error messages, you should try to take a network trace.

I usually prefer tcpdump over HP-UX's native "nettl" tool, but it might be difficult to find an easy-to-install package of tcpdump for HP-UX 10.20 these days.
So here's a tutorial on getting a network trace on HP-UX's native tools:
http://www.compute-aid.com/nettl.html

Instead of formatting the trace using the netfmt command, you might want to download a copy of Wireshark (previously known as Ethereal).
http://www.wireshark.org/
It's a heavy-duty network traffic analysis program, which can read the traces created by nettl. You can run this on any Unix or Windows host, whichever is more convenient to you. Of course, some understanding of TCP/IP internals is required to fully use the capabilities of Wireshark... but you might at least be able to use Wireshark to "trim down" the trace to contain only the data related to this FTP connection, and then maybe allow us here on this forum to see it.

Be aware that FTP transfers passwords in plaintext, so they are easily recoverable from network traces like this.

MK

[Phillip Popp]

Matti,
Thanks for that piece of info. The freezing does happen at the ls (listing of the remote directory). It says " opening ASCII mode data connection for /usr/bin/ls" then waits there. I did it on the command line in Unix and it gave me the listing after about 5 minutes. This would explain things. My scripts or the server itself must time out before this. I will try to lenghten the time out time on just Filezilla to see what happens. Maybe the firewall for this needs to be adjusted, when you say harder to get through a fire wall, can you be more specific on the difficulties. What about actually transferring files, does that require two connections as well, two sockets maybe?

Thanks

This is really helping me work through this issue.

Phil

[Tim Nelson]

Matti, Thanks for correcting me, I hear kermit and think olden days.


Phillip, FTP is native/included with HPUX (unless it has been stripped out for some reason). ( man ftp). Certainly there has to be port 21 services open and an ftp service running on the remote in order to use it. I would guess that IF there is scripted kermit using an FTP module there would/should be little difference then.

Manually running a ftp connection may help you troubleshoot.

( i.e. ftp ftpserver.berkely.edu)
should get a login prompt
should get a password prompt
should get a ftp propmt
should be able to execute ls, dir, get, put, etc...

[Tim Nelson]

Previous post was a little slow.

A 5 minute delay in a directory listing would most likely indicate terrible network performance. If you eventually got the listing back I would not suspect a FW issue. Is the listing just that long to take 5 minutes or is there a huge delay before the listing ?

FYI, FTP uses two ports, 1 for commands(21) and 1 for data(>1024), either in an active or passive configuration.

[Phillip Popp]

Hi,
Not a real long list. It never took that long before. I am now trying to do a get by command line. 15101 bytes. Lets see if it times out, or actually just takes forever.

Thanks,

Phil

[Steven Schweda]

> I am using a script to push data from an
> overseas server to my server here in
> America.

Push or pull? Where are you running Kermit,
and are you fetching or sending? As I read
the .debuglog file, you're connecting to a
system in China, and doing an "mget", which
I'd describe as pulling data from there to
here, not pushing it from the other end.

You might wish to change that password soon,
too.

Looking for the telltale " FTP SENT ", I see
(after some preliminaries):

[...]
04:36:07.533 ftp mget remote_files A[*.std*]=1
[...]
04:36:07.534 ftp remote_files arg[*.std*]
[...]
04:36:08.103 FTP SENT [NLST *.std*]
[...]
04:36:08.286 FTP RCVD [550 *.std*: No such file or directory.]
[...]
04:36:08.378 FTP SENT [QUIT]
[...]
04:36:08.565 FTP RCVD [221 Goodbye!]
[...]

So, knowing nothing, I'd say that you're
trying to fetch files which do not exist
where you seek them. What, exactly, were
you expecting this script to do, and is it
actually possible?

It might help to see the original Kermit
script in a less encrypted form (but perhaps
not).

You might also find "wget" to be useful if
you're actually pulling and not pushing.

[Dennis Handly]

>The freezing does happen at the ls. It says " opening ASCII mode data connection for /usr/bin/ls" then waits there. I did it on the command line in Unix and it gave me the listing after about 5 minutes.

I've had cases where ftp hangs forever on the ls. I have to use "passive" to get it to work.

[Steven Schweda]

> I have to use "passive" to get it to work.

In the .debuglog file:

[...]
04:36:07.725 ftpcmd cmd[PASV]
[...]
04:36:07.726 FTP SENT [PASV]
[...]
04:36:07.911 FTP RCVD [227 Entering Passive Mode (221,224,24,87,16,133)]
[...]

That was before:

[...]
04:36:08.101 ftp recvrequest cmd[NLST]
[...]
04:36:08.103 FTP SENT [NLST *.std*]
[...]

If the "freezing" interactive FTP job was not
done in passive mode, then a firewall could
affect it differently.