bug in java.net.Socket??

[horos]

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

 

[EJP]

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.

 

[horos]

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

 

[Lew]

No.. [sic] 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 [sic] 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 [sic] 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 [sic]-based ftp
clients?

I'll bet you ten bucks it's not a bug in the API but in your code.

This is the time for an SSCCE.
<http://sscce.org/>

 

[Arne Vajhøj]

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?

http://commons.apache.org/net/

Arne

 

[EJP]

The only thing that makes sense is that the SYN_SENT packet
being sent somehow differs between Socket APIs.

And as neither of the APIs actually sends a SYN_SENT at all, you have
therefore ruled out the APIs completely. The SYN_SENT is sent by the
*kernel* as part of the execution of the connect() system call. All that
Java and .NET and everything else do is call connect(). They certainly
don't send out SYN or ACK or FIN or RST packets themselves.

 

[horos]

And as neither of the APIs actually sends a SYN_SENT at all, you have
therefore ruled out the APIs completely. The SYN_SENT is sent by the
*kernel* as part of the execution of the connect() system call. All that
Java and .NET and everything else do is call connect(). They certainly
don't send out SYN or ACK or FIN or RST packets themselves.

Hmm. Good point. That's just odd then. Maybe it's a timing issue - ie,
the SYN_SENT is made before the server is ready to receive it; the
work is done in separate threads.. I'm open to other ideas here
though.

Anyways, I'll check it out and let everyone know the conclusion, it
certainly is an odd bug to have (considering that as I said it was
working for a year before suddenly breaking).

Ed

 

[EJP]

Hmm. Good point. That's just odd then. Maybe it's a timing issue - ie,
the SYN_SENT is made before the server is ready to receive it

Nope. In that case the server host will respond with an ICMP RST, which
cause an errno=ECONN at the client, which manifests itself in Java as a
java.net.ConnectException 'connection refused'.

In any case it is almost certain that the FTP server will establish the
listening socket *first* and then discover its port number and send it
to the client - there's no other sensible way to implement that.

Anyways, I'll check it out and let everyone know the conclusion, it
certainly is an odd bug to have (considering that as I said it was
working for a year before suddenly breaking).

I suggest you investigate the firewall scenario that I and others
mentioned before. That is very likely to have changed unannounced.

 

[Nigel Wade]

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.

The most likely reason is that something is dropping that SYN packet, or
the response. If the SYN was received by a listening server it would
respond with a SYN/ACK. If there is nothing listening then the host
responds with an RST. The only scenario that I can think of where a SYN
is sent but no SYN/ACK or RST is returned is if the server socket is
setup to queue connections (it's quite a while since I did any work at
this level so my memory is very hazy on the actual specifics). If the
server is already serving a connection new connection attempts are
queued, up to some set limit, until they are either accepted or time out.

You should look at the network traffic on the client and server to see
what packets are really being sent and received. Also check the server to
see what connections it already has established and whether it queues
requests. I would suspect a mis-configured (or misunderstood) firewall
somewhere in the route.

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.

Java is not responsible for the SYN-SYN/ACK-ACK three-way handshake. Java
works at the process layer (layers 5, 6 & 7 of the OSI 7-layer model).
This handshake takes place at the transport layer (level 4 in OSI). Java
relies on the OS via system calls to handle the lower layers. I see no
way that a bug in Java could cause symptoms you describe.

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.

I disagree. I don't see how this is due to a bug in Java.