Prev: Table pagination for about 40 rows per page
Next: JTable column sizing
From: horos on 9 Feb 2010 23:51
All,

I've been trying to get a passive ftp server working, but
unfortunately, there seems to be a VERY low level bug in the Socket
command that makes the passive connection.

The symptoms: I get a port to connect to, and then try that port
using:

Socket sckt = new Socket(host, port);

The socket sends off a SYN_SENT but hangs in waiting for response.

Now I don't know for sure, but I STRONGLY suspect that it is a java
bug. Why? The Socket connection worked before (ie: this is old
production code). Regular ftp worked. Net::FTP, the perl
implementation of ftp works.

So it looks like there is a strong likelihood there is a bug in socket
itself. I'd love to hear from sun on this one, I can both demo the
code that isn't working, and hopefully file a bug report.. I''m on
jdk6.12, but am upgrading to jdk6.18.

Ed

Ed
From: Peter Duniho on 10 Feb 2010 00:29
horos wrote:
> All,
>
> I've been trying to get a passive ftp server working, but
> unfortunately, there seems to be a VERY low level bug in the Socket
> command that makes the passive connection.
>
> The symptoms: I get a port to connect to, and then try that port
> using:
>
> Socket sckt = new Socket(host, port);
>
> The socket sends off a SYN_SENT but hangs in waiting for response.
>
> Now I don't know for sure, but I STRONGLY suspect that it is a java
> bug. [...]

Regardless of your analysis, the likelihood of there being a bug in the
java.net.Socket class, especially one like that, is incredibly low.

It is much more likely that either your own code is flawed somehow, or
the network configuration (either locally or remotely) has changed,
preventing the connection from succeeding for some reason.

Pete
From: EJP on 10 Feb 2010 00:39
On 10/02/2010 3:51 PM, horos wrote:
Doesn't sound very likely, does it. java.net.Socket has a bug just in
this one case where someone has sent a PASV command along another
connection?

More likely the passive server is responding with a port number that its
firewall isn't configured for, and is dropping packets to.
From: Thomas Pornin on 10 Feb 2010 04:01
According to horos <horos22(a)gmail.com>:
> The symptoms: I get a port to connect to, and then try that port
> using:
>
> Socket sckt = new Socket(host, port);
>
> The socket sends off a SYN_SENT but hangs in waiting for response.
>
> Now I don't know for sure, but I STRONGLY suspect that it is a java
> bug.

If the SYN packet was emitted then, by definition, the client code (the
Java code which creates a Socket instance) is fine and does what it is
told. The server should respond with a ACK+SYN packet. If that packet
does not come back, then either the _server_ has a bug, or (more
probably) some firewall went in the way of the packets, dropping either
the client-sent SYN or the server-sent ACK+SYN.

FTP passive mode usually entails choosing a random port, contrary to
active FTP where a well-known port is used. Firewalls seldom approve of
random ports.


--Thomas Pornin
From: horos on 10 Feb 2010 12:59
On Feb 10, 1:01 am, Thomas Pornin <por...(a)bolet.org> wrote:
> According to horos  <horo...(a)gmail.com>:
>
> > The symptoms: I get a port to connect to, and then try that port
> > using:
>
> > Socket sckt = new Socket(host, port);
>
> > The socket sends off a SYN_SENT but hangs in waiting for response.
>
> > Now I don't know for sure, but I STRONGLY suspect that it is a java
> > bug.
>
> If the SYN packet was emitted then, by definition, the client code (the
> Java code which creates a Socket instance) is fine and does what it is
> told. The server should respond with a ACK+SYN packet. If that packet
> does not come back, then either the _server_ has a bug, or (more
> probably) some firewall went in the way of the packets, dropping either
> the client-sent SYN or the server-sent ACK+SYN.
>
> FTP passive mode usually entails choosing a random port, contrary to
> active FTP where a well-known port is used. Firewalls seldom approve of
> random ports.
>
>         --Thomas Pornin


No.. I've controlled for all of this:

1. Regular, vanilla ftp works (passively, on the same box, connecting
to the same server, same user and password).
2. The perl wrapper Net::FTP works (passively on the same box,
connecting to the same server, same user and password).
3. The interface worked before in its assigned function (doing vanilla
ftp - the underlying API is j-ftp), and had worked for about a year.
It just stopped working.

In fact, I've automated the testing so that the same passive port
(which is randomly generated) comes up in both Net::FTP and the java
API version. Net::FTP works with the assigned port (and gets an
established connection, as well as vanilla FTP), the java API version
doesn't. The only thing that makes sense is that the SYN_SENT packet
being sent somehow differs between Socket APIs.

I suppose the next step would be testing a different java ftp client,
and see if I can replicate the behavior with this other client. I'm
welcome as to suggestions for this - what are some good java-based ftp
clients?

Ed
 |  Next  |  Last
Pages: 1 2 3
Prev: Table pagination for about 40 rows per page
Next: JTable column sizing