I know just enough about tcpdump to frustrate myself…

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?

Advertisements

4 Comments

Filed under Uncategorized

4 responses to “I know just enough about tcpdump to frustrate myself…

  1. cardinalximinez

    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.

  2. sylvar

    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.

  3. cardinalximinez

    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

  4. h_postmortemus

    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…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s