I know just enough about tcpdump to frustrate myself...

[sylvar]

On the off chance that someone will know what's going on here...

I'm trying to FTP a file to a server. At my console on helpdesk.tblc.org, I see this:

> ftp 128.222.117.50
Connected to 128.222.117.50.
[pause]
421 Service not available, remote server has closed connection


And here's what tcpdump sees:



# tcpdump -vv port ftp or ftp-data
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
12:59:38.662394 IP (tos 0x0, ttl 64, id 142, offset 0, flags [DF], proto 6, length: 60) helpdesk.tblc.org.59894 > 128.222.117.50.ftp: S [tcp sum ok] 3272299267:3272299267(0) win 5840 <mss 1460,sackOK,timestamp 2007454605 0,nop,wscale 2>
12:59:38.662563 IP (tos 0x0, ttl 64, id 39531, offset 0, flags [none], proto 6, length: 44) 128.222.117.50.ftp > helpdesk.tblc.org.59894: S [tcp sum ok] 2803279614:2803279614(0) ack 3272299268 win 16352 <mss 1460>
12:59:38.662586 IP (tos 0x0, ttl 64, id 144, offset 0, flags [DF], proto 6, length: 40) helpdesk.tblc.org.59894 > 128.222.117.50.ftp: . [tcp sum ok] 1:1(0) ack 1 win 5840
12:59:48.703604 IP (tos 0x0, ttl 64, id 39558, offset 0, flags [none], proto 6, length: 40) 128.222.117.50.ftp > helpdesk.tblc.org.59894: F [tcp sum ok] 1:1(0) ack 1 win 16352
12:59:48.703934 IP (tos 0x10, ttl 64, id 146, offset 0, flags [DF], proto 6, length: 40) helpdesk.tblc.org.59894 > 128.222.117.50.ftp: F [tcp sum ok] 1:1(0) ack 2 win 5840
12:59:48.704098 IP (tos 0x0, ttl 64, id 39559, offset 0, flags [DF], proto 6, length: 40) 128.222.117.50.ftp > helpdesk.tblc.org.59894: . [tcp sum ok] 2:2(0) ack 2 win 16351

6 packets captured
6 packets received by filter
0 packets dropped by kernel




So... anyone have any ideas what's going on here?

Comments

[ximinez]

Try using passive mode. It's pasv in most command-line ftp programs that I know of.

I'll leave the long technical explanation as to why as an exercise for the reader.

[sylvar.livejournal.com]

Hmm... man ncftpput says The default is to use passive, but to fallback to regular if the passive connection fails or times out.

Just in case, I tried explicitly passing -F (use PASV) to ncftpput, but that didn't help.

Unfortunately, I don't think it ever even manages to send the PASV command. I think the connection drops before it can even send USER and PASS.

[ximinez]

Hm. It's hard to be sure just from the tcpdump, because that crap is just hard to read. You might want to use ethereal (which changed its name recently, but hell if I remember what it was).

Barring more info, the things I'd try are:
- a different client program (in case of a bug)
- a different client machine (in case of firewall problems)
- a different, known working destination server.
- combinations of the above

[h-postmortemus.livejournal.com]

Hard to tell without a full packet dump, since I can't see the actual protocol chatter.
PASV may or may not help.
Could be TCP-wrappers or identd issue.
Could be a firewall issue on your end, filtering some of the inbound traffic...