Prev: Table pagination for about 40 rows per page
Next: JTable column sizing
From: Lew on 10 Feb 2010 13:10
Thomas Pornin wrote:
>> 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.

horos wrote:
> 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/>

--
Lew
From: Arne Vajhøj on 10 Feb 2010 18:19
On 10-02-2010 12:59, horos wrote:
> 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

From: EJP on 10 Feb 2010 18:57
On 11/02/2010 4:59 AM, horos wrote:
> 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.
From: horos on 10 Feb 2010 20:26
On Feb 10, 3:57 pm, EJP <esmond.not.p...(a)not.bigpond.com> wrote:
> On 11/02/2010 4:59 AM, horos wrote:
>
> > 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.

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
From: EJP on 11 Feb 2010 01:19
On 11/02/2010 12:26 PM, horos wrote:
> 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.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Table pagination for about 40 rows per page
Next: JTable column sizing