LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Fedora
User Name
Password
Fedora This forum is for the discussion of the Fedora Project.

Notices

Reply
 
Search this Thread
Old 06-10-2008, 09:16 AM   #1
peterb
Member
 
Registered: Aug 2003
Location: Athens, Greece
Distribution: Mandriva, Fedora
Posts: 127

Rep: Reputation: 15
active ftp port iptables problem


Hello all,

This is a bit of a strange problem that happened shortly after my ups gave out. Normally I access ftp using active rather than passive but today when I tried to ftp into my fedora system it starts to connect and then simply hangs.

I have searched through the forum and found only partial information.
I did an fsck and that didn't help. I can ftp into the system by changing the settings on my windows client to passive so I know that this is working.

After checking my fedora system secure log, I noticed that it says:
sshd: server listening on port 22.
sshd: error Bind to port 22 on 0.0.0.0 failed: already in use.

I then checked my iptables and they look normal:
chain input forward output policy accept
I do not use a firewall as this is only for internat use.

One peculiar aspect here is that when I try to restart iptables through services, it just hangs.

Does anyone have some ideas as to what can be corrected here?

I am assuming that some file may be corrupted.

Peter
 
Old 06-11-2008, 11:31 PM   #2
ramram29
Member
 
Registered: Jul 2003
Location: Miami, Florida, USA
Distribution: Debian
Posts: 848
Blog Entries: 1

Rep: Reputation: 47
port 22 is not ftp but ssh.
 
Old 06-11-2008, 11:39 PM   #3
dkm999
Member
 
Registered: Nov 2006
Location: Seattle, WA
Distribution: Fedora
Posts: 407

Rep: Reputation: 35
FTP is an odd case. In all FTP connections, the client (your Windoze box) initiates a connection on TCP port 21 to the server. This is called the control connection. In active mode, when you give a command that will produce lots of data (like ls, get or put), the server initiates a reverse connection toward the client on TCP port 20. In contrast, in passive mode, the server sends back a message to the client on the control connection, saying that it will listen on port xxx for data. It then waits for the client to initiate the data connection on that port.

If your ftpd is screwed up, it could be trying to use some other port for data in the active mode, I guess. It would be worth finding out which daemons are listening to what; to do so, use the command
Code:
netstat -tanp
This will give you a listing of all the TCP ports that some process is listening on. Since you suspect port 22, there might not be a sshd daemon listening on that one; see who is.
 
Old 06-12-2008, 01:31 AM   #4
peterb
Member
 
Registered: Aug 2003
Location: Athens, Greece
Distribution: Mandriva, Fedora
Posts: 127

Original Poster
Rep: Reputation: 15
Thanks for the info dkm999.

I tried that command
and can see that 21 is allocated to vsftpd
22 is set to sshd

The system email gave me this:
error setting IPV6_V6ONLY: Protocol not available
Failed binding to ::, port 21: Address already in use
Check the ServerType directive to ensure you are configured correctly.

So I guess that I will have to check my config files to see what changed.

Last edited by peterb; 06-12-2008 at 04:04 AM.
 
Old 06-12-2008, 11:15 AM   #5
dkm999
Member
 
Registered: Nov 2006
Location: Seattle, WA
Distribution: Fedora
Posts: 407

Rep: Reputation: 35
That may be a blind alley; the report of failure to connect to ::,port 21 is saying that it could not get access to the IPv6 port 21, possibly because you are not running any IPv6 interfaces. In any case, what you want to be sure of is that, since vsftpd has a good grip on IPv4 port 21, it can also initiate a connection on port 20 outbound to your Windoze machine.

I would recommend that you first check the /etc/vsftpd.conf file. My manpage (quite out of date) says that there are two parameters that could be interesting: connect_from_port_20 (YES), and ftp_data_port (20). And then you might try setting log_ftp_protocol=YES. This should produce some info in /var/log/vsftpd.log.

If all else fails, my fallback strategy is to use tcpdump to capture a trace of the packets going between your server and the Windows machine. The interpretation could be a bit of a problem, but at least you will be able to see at what point the communication breaks down.
 
Old 06-13-2008, 07:09 AM   #6
peterb
Member
 
Registered: Aug 2003
Location: Athens, Greece
Distribution: Mandriva, Fedora
Posts: 127

Original Poster
Rep: Reputation: 15
Hello dkm999,

I added

Doing a search in the forum here I also came across an interesting fact that sometimes the windoze systems are the culprit.
One of them mentioned ip_conntrack_ftp but I have not been able to find this on my fedora system using grep -il

Using the command you mentioned earlier again after checking files and making a few minor changes resulted as follows:
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:33763 0.0.0.0:* LISTEN 1667/rpc.statd
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 1974/mysqld
tcp 0 0 0.0.0.0:5900 0.0.0.0:* LISTEN 2632/vino-server
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 1648/portmap
tcp 0 0 127.0.0.1:50000 0.0.0.0:* LISTEN 1881/hpiod
tcp 0 0 127.0.0.1:50002 0.0.0.0:* LISTEN 1886/python
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 3518/vsftpd
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 2028/sendmail: acce
tcp 0 0 192.168.1.11:21 192.168.1.30:1346 ESTABLISHED 3567/vsftpd
tcp 0 0 :::110 :::* LISTEN 2002/dovecot
tcp 0 0 :::143 :::* LISTEN 2002/dovecot
tcp 0 0 :::80 :::* LISTEN 2056/httpd
tcp 0 0 :::22 :::* LISTEN 1899/sshd

I am starting to wonder if the problem is on my windoze system since I am not seeing any real evidence towards the linux system.

I will do the tcpdump and see what that will show.

Thanks,
Peter
 
Old 06-13-2008, 11:31 AM   #7
dkm999
Member
 
Registered: Nov 2006
Location: Seattle, WA
Distribution: Fedora
Posts: 407

Rep: Reputation: 35
I think that is a good approach. According to the netstat listing you posted, everything seems just fine at your Linux system. Your vsftpd daemon is listening for new control channel connections from anywhere, and it had an active connection to one client (presumably your Windoze box).

Once you start the tcpdump capture, try to do a directory listing over the FTP connection. That should cause the data channel connection on TCP port 20 to open.
 
Old 06-14-2008, 05:45 AM   #8
peterb
Member
 
Registered: Aug 2003
Location: Athens, Greece
Distribution: Mandriva, Fedora
Posts: 127

Original Poster
Rep: Reputation: 15
Did the tcpdump out of curiosity but I don't really know whether or not this is giving me a better clue.
This is from the windoze system that I now consider having the problem.
Once it connects, the directory listing just freezes for a while and then it just stops. I clicked to refresh the listing (shown towards the bottom) but still no listing in active mode.

I would guess that the acks are the delay.

Peter

15:07:22.549594 IP 192.168.1.30.orion > pab.cxm.ftp: P 62:87(25) ack 278 win 17243
15:07:22.560054 IP pab.cxm.ftp > 192.168.1.30.orion: P 278:329(51) ack 87 win 5840
15:07:22.565201 IP 192.168.1.30.orion > pab.cxm.ftp: P 87:93(6) ack 329 win 17192
15:07:22.572490 IP pab.cxm.ftp-data > 192.168.1.30.optimanet: S 1394217637:1394217637(0) win 5840 <mss 1460,sackOK,timestamp 15536273 0,nop,wscale 4>
15:07:22.604897 IP pab.cxm.ftp > 192.168.1.30.orion: . ack 93 win 5840
15:07:25.571178 IP pab.cxm.ftp-data > 192.168.1.30.optimanet: S 1394217637:1394217637(0) win 5840 <mss 1460,sackOK,timestamp 15539273 0,nop,wscale 4>
15:07:31.569731 IP pab.cxm.ftp-data > 192.168.1.30.optimanet: S 1394217637:1394217637(0) win 5840 <mss 1460,sackOK,timestamp 15545273 0,nop,wscale 4>
15:07:34.112638 IP 192.168.1.30.orion > pab.cxm.ftp: P 93:99(6) ack 329 win 17192
15:07:34.112744 IP pab.cxm.ftp > 192.168.1.30.orion: . ack 99 win 5840
15:07:41.527622 IP 192.168.1.1.router > 192.168.1.255.router: RIPv1, Response, length: 44
15:07:43.566844 IP pab.cxm.ftp-data > 192.168.1.30.optimanet: S 1394217637:1394217637(0) win 5840 <mss 1460,sackOK,timestamp 15557273 0,nop,wscale 4>
15:08:01.863932 IP 192.168.1.30.orion > pab.cxm.ftp: P 99:105(6) ack 329 win 17192
15:08:01.864035 IP pab.cxm.ftp > 192.168.1.30.orion: . ack 105 win 5840
15:08:06.862176 arp who-has 192.168.1.30 tell aurora.linux.cxm
15:08:06.862307 arp reply 192.168.1.30 is-at 00:1d:60:a7:18:cb (oui Unknown)
15:08:07.561050 IP pab.cxm.ftp-data > 192.168.1.30.optimanet: S 1394217637:1394217637(0) win 5840 <mss 1460,sackOK,timestamp 15581273 0,nop,wscale 4>
15:08:11.528352 IP 192.168.1.1.router > 192.168.1.255.router: RIPv1, Response, length: 44
15:08:22.560527 IP pab.cxm.ftp > 192.168.1.30.orion: P 329:366(37) ack 105 win 5840
15:08:22.561027 IP pab.cxm.ftp > 192.168.1.30.orion: P 366:416(50) ack 105 win 5840
15:08:22.561172 IP 192.168.1.30.orion > pab.cxm.ftp: . ack 416 win 17105
15:08:22.561481 IP pab.cxm.ftp > 192.168.1.30.orion: P 416:466(50) ack 105 win 5840
15:08:22.568032 IP 192.168.1.30.orion > pab.cxm.ftp: P 105:130(25) ack 466 win 17055
15:08:22.568144 IP pab.cxm.ftp > 192.168.1.30.orion: . ack 130 win 5840
15:08:22.568855 IP pab.cxm.ftp > 192.168.1.30.orion: P 466:517(51) ack 130 win 5840
15:08:22.583654 IP 192.168.1.30.orion > pab.cxm.ftp: P 130:136(6) ack 517 win 17004
15:08:22.623411 IP pab.cxm.ftp > 192.168.1.30.orion: . ack 136 win 5840
15:08:22.677248 IP pab.cxm.ftp-data > 192.168.1.30.sns-protocol: S 1458018723:1458018723(0) win 5840 <mss 1460,sackOK,timestamp 15596392 0,nop,wscale 4>
15:08:25.675677 IP pab.cxm.ftp-data > 192.168.1.30.sns-protocol: S 1458018723:1458018723(0) win 5840 <mss 1460,sackOK,timestamp 15599392 0,nop,wscale 4>
15:08:31.674231 IP pab.cxm.ftp-data > 192.168.1.30.sns-protocol: S 1458018723:1458018723(0) win 5840 <mss 1460,sackOK,timestamp 15605392 0,nop,wscale 4>
15:08:41.530949 IP 192.168.1.1.router > 192.168.1.255.router: RIPv1, Response, length: 44
15:08:43.671347 IP pab.cxm.ftp-data > 192.168.1.30.sns-protocol: S 1458018723:1458018723(0) win 5840 <mss 1460,sackOK,timestamp 15617392 0,nop,wscale 4>
15:08:46.412850 IP 192.168.1.30.orion > pab.cxm.ftp: P 136:142(6) ack 517 win 17004
15:08:46.412952 IP pab.cxm.ftp > 192.168.1.30.orion: . ack 142 win 5840
15:08:56.413216 IP 192.168.1.30.orion > pab.cxm.ftp: R 142:142(0) ack 517 win 0
15:09:07.665552 IP pab.cxm.ftp-data > 192.168.1.30.sns-protocol: S 1458018723:1458018723(0) win 5840 <mss 1460,sackOK,timestamp 15641392 0,nop,wscale 4>
15:09:11.531636 IP 192.168.1.1.router > 192.168.1.255.router: RIPv1, Response, length: 44
15:09:12.664303 arp who-has 192.168.1.30 tell aurora.linux.cxm
15:09:12.664436 arp reply 192.168.1.30 is-at 00:1d:60:a7:18:cb (oui Unknown)
15:09:22.662772 IP pab.cxm.53493 > 192.168.1.30.orion: R 1397406771:1397406771(0) ack 489116212 win 5840
15:09:32.355194 arp who-has 192.168.1.1 tell 192.168.1.30
15:09:41.534207 IP 192.168.1.1.router > 192.168.1.255.router: RIPv1, Response, length: 44
 
Old 06-14-2008, 12:55 PM   #9
dkm999
Member
 
Registered: Nov 2006
Location: Seattle, WA
Distribution: Fedora
Posts: 407

Rep: Reputation: 35
From what I can divine off this tcpdump listing, it appears that the Windoze system (192.168.1.30) is not replying on the ftp-data port (tcp 20). From the top of the listing in your last post, the first three lines indicate that a command was sent from 192.168.1.30 to pab.cxm on the ftp port (21), that packet was acknowledged, and the Windoze box replied that it had seen the acknowledgment.

The very next thing that happens is that the Linux box tries to open a data channel (TCP port 20, aka ftp-data), but gets no reply to that attempt. The Linux box retries this a total of 4 times and then gives up.

So there are two possibilities: either the Windoze system is not seeing the initial connection packet, or it is failing to reply. Either of these could be due to a faulty configuration on the Windows firewall. How to diagnose this depends, of course, on which version of Windoze you are running. On my XP systems, you can get at the relevant config page this way:

Start\Control Panel\Windows Firewall\Advanced\{choose your LAN interface}\Settings

This will bring up a list of checkboxes saying what services the firewall will allow through. Make sure that FTP Server is checked, and see if that makes a difference.

Good luck.
 
Old 06-15-2008, 01:42 AM   #10
peterb
Member
 
Registered: Aug 2003
Location: Athens, Greece
Distribution: Mandriva, Fedora
Posts: 127

Original Poster
Rep: Reputation: 15
Amazing what a little help can accomplish.

The answer to this mystery from what you told me was just about on the spot.

For some reason in the windose firewall exceptions, the file and printer sharing was unchecked. The oddity of this is that it could have only happen either as a glitch or from a windows update that occurred during these days.

In any case, once this is enabled, the ftp works normally in active mode.

This is one of those times where a clear answer is now available to this problem.

Thanks,

Peter
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
IPTABLES rules for active FTP TruckStuff Linux - Security 7 04-22-2009 06:21 PM
iptables masquerading & active ftp connections PowerMatt Linux - Networking 2 10-20-2005 05:02 PM
iptables, nmap and active ftp connections Bug Linux - Security 3 06-14-2004 01:14 PM
Another iptables Active FTP Issue tnolte Linux - Networking 4 09-28-2003 11:34 AM
ftp and ftp port forwarding with IPtables?? FunkFlex Linux - Security 3 04-24-2002 03:03 AM


All times are GMT -5. The time now is 01:36 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration