from:"Bogdan Drozdowski \(JIRA\)"

[jira] [Commented] (NET-579) SSL/TLS SocketClients do not verify the hostname against the certificate

2015-08-22 Thread Bogdan Drozdowski (JIRA)


[ 
https://issues.apache.org/jira/browse/NET-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14708046#comment-14708046
 ] 

Bogdan Drozdowski commented on NET-579:
---

The patch looks nice, but you can already achieve this functionality - you can 
always set  your own TrustManager in the client instance, e.g. 
FTPSClient.setTrustManager(), or use a custom SocketFactory.
This wouldn't require Java 7 by Commons-NET, would allow to set even more 
parameters than these and enable any certificate validations you would wish. 
Sure, it's less convenient, because you have to code more on the client side.
I'm not a Commons-NET developer, but I don't think I'd like such a change in 
the code. The problem is that a certificate can be issued to a host name and 
thus connecting using an IP address would fail or vice versa (a test 
certificate issued for an IP address inside some local network, and clients 
connecting with hostnames by a local DNS).

 SSL/TLS SocketClients do not verify the hostname against the certificate
 

 Key: NET-579
 URL: https://issues.apache.org/jira/browse/NET-579
 Project: Commons Net
  Issue Type: Bug
  Components: FTP, IMAP, POP3, SMTP
Affects Versions: 3.3
 Environment: Java 1.7 (earlier versions cannot verify the hostname)
Reporter: Simon Arlott
Priority: Critical
  Labels: security
 Attachments: NET-579.patch

   Original Estimate: 2h
  Remaining Estimate: 2h

 Every subclass of SocketClient that does SSL/TLS will never verify the 
 hostname of the server against the certificate. This means that any valid 
 certificate for any CA in the default trust store will be accepted without 
 error.
 SocketClient should be modified to store the hostname, and 
 SMTPSClient/FTPSClient/IMAPSClient/POP3SClient should use it when negotiating 
 SSL/TLS.
 Java 1.7 has support for verifying the hostname if 
 SSLParameters.setEndpointIdentificationAlgorithm(HTTPS) is used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (NET-468) Request for native support for socks proxy routing with Commons net FTP

2012-07-14 Thread Bogdan Drozdowski (JIRA)

[
https://issues.apache.org/jira/browse/NET-468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13414348#comment-13414348
]

Bogdan Drozdowski commented on NET-468:
---

Yes, it would be faster to run the test this way, it wouldn't use any bandwidth
or resources of existing servers and it wouldn't fail if the external servers
become inaccessible for maintenance periods. The same could be implemented for
other protocols. The would probably do for simple tests.
The problem with this approach is that we would be testing our software not
only with another piece of our software, but also with not-so-real-life
software. The authors of the embedded server could implement something in a
specific way that could, for example, work if we implement FTPClient the same
way but would make FTPClient fail when connecting to real servers (or
vice-versa: connecting to real servers would work, but tests would fail). This
could be especially the case with the Socks protocol (like I wrote before, not
all Socks servers seem to work with Java).
Another approach would be seeting up some test servers (using commonly-used
software, like ProFTPd or vsftpd for FTP) so that no resources outside
apache.org would be needed.

Request for native support for socks proxy routing with Commons net FTP
---

Key: NET-468
URL: https://issues.apache.org/jira/browse/NET-468
Project: Commons Net
Issue Type: Improvement
Components: FTP
Affects Versions: 1.4, 2.0, 3.0.1, 3.1
Environment: We use commons net in out products for all
communication to an FTP server. OS : All. No other environment specifications.
Reporter: Ramya Rajendiran
Attachments: sockclient-proxy3.diff, sockclient-proxy4.diff,
sockclient-proxy5.diff, sockclient-proxy6.diff, sockclient-proxy7.diff

Commons net currently does not natively support connection to an FTP server
via a socks proxy. The only way of achieving this would be to work at the
socket level as observed here
http://wiki.apache.org/commons/Net/FrequentlyAskedQuestions. (by setting JVM
properties socksProxyPort and socksProxyPortHost)
However, a major side effect of this all connections on this JVM will go
through the socks proxy since this setting is at the JVM level. This is
sometimes undesirable as the business requirements are such that only certain
applications on the JVM need to go through the socks proxy. There are no
existing workarounds to conditionally prevent other applications to not be
routed through the socks proxy. This makes our application which consumes the
commons net unusable for such businesses.
Providing native support for socks proxy with commons net for FTP, will go a
long way in supporting such common scenarios and business continuity.
Therefore raising this enhancement request.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (NET-468) Request for native support for socks proxy routing with Commons net FTP

2012-07-05 Thread Bogdan Drozdowski (JIRA)

[
https://issues.apache.org/jira/browse/NET-468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Bogdan Drozdowski updated NET-468:
--

Attachment: sockclient-proxy4.diff

OK, the last version. This time created with the svn diff command. If you wish
to receive only such patches, write that on the
http://commons.apache.org/net/code-standards.html page. If you don't want to
receive patches, simply disable this functionality or make this JIRA private.
If you don't like this patch, simply say rejected and don't bother
explaining. I also have other things to do in my spare time.

Request for native support for socks proxy routing with Commons net FTP
---

[jira] [Updated] (NET-468) Request for native support for socks proxy routing with Commons net FTP

2012-07-04 Thread Bogdan Drozdowski (JIRA)

[
https://issues.apache.org/jira/browse/NET-468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Bogdan Drozdowski updated NET-468:
--

Attachment: (was: sockclient-proxy2.diff)

Request for native support for socks proxy routing with Commons net FTP
---

[jira] [Updated] (NET-468) Request for native support for socks proxy routing with Commons net FTP

2012-07-04 Thread Bogdan Drozdowski (JIRA)

[
https://issues.apache.org/jira/browse/NET-468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Bogdan Drozdowski updated NET-468:
--

Attachment: sockclient-proxy3.diff

No, I didn't use the SVN diff command to create the patch. I prefer to keep my
working copy clean, so I copy the files I wish to modify somewhere else and
perform a diff -buraN command. To apply the patch, use the patch utility,
common in many Linux distributions. The command will be something similar to
{code}patch -F20 -p0 /path/to/sockclient-proxy2.diff{code}
(run in the directory that contains the src directory). If that's a problem,
I can use svn diff.
The previous patch had an error - the test wasn't in src/test. Use the third
version I've just attached.

Request for native support for socks proxy routing with Commons net FTP
---

[jira] [Updated] (NET-462) FTPClient in PASSIVE_LOCAL_DATA_CONNECTION_MODE cannot work when host have several different IP

2012-07-04 Thread Bogdan Drozdowski (JIRA)


 [ 
https://issues.apache.org/jira/browse/NET-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bogdan Drozdowski updated NET-462:
--

Attachment: ftp-bindlocal.diff

The attached patch fixes this by adding a new field in FTPClient. By calling 
setPassiveLocalIPAddress(), you can set the local address to bind to. The field 
will be used in the same place as in your code (but it is a separate value from 
what getHostAddress returns).
In the meantime, you can create and install your own SocketFactory in the 
FTPClient. You can take DefaultSocketFactory class as an example and make you 
own factory, which will create sockes already bound to your local address. This 
will work even with the older versions of Commons-Net.

 FTPClient in PASSIVE_LOCAL_DATA_CONNECTION_MODE cannot work when host have 
 several different IP
 ---

 Key: NET-462
 URL: https://issues.apache.org/jira/browse/NET-462
 Project: Commons Net
  Issue Type: Improvement
  Components: FTP
Affects Versions: 3.1
 Environment: All OS,for example linux or windows and so on
Reporter: Junsheng Chen
Priority: Minor
  Labels: ActiveIp, FTPClient, PASSIVE_LOCAL_DATA_CONNECTION_MODE
 Fix For: 3.2

 Attachments: ftp-bindlocal.diff

   Original Estimate: 24h
  Remaining Estimate: 24h

 When host have several different IP and client setting to 
 PASSIVE_LOCAL_DATA_CONNECTION_MODE，_openDataConnection_ creating socket may 
 use the unexpected ip。
 For example, The host have two Ips, one for intra and the another for extern, 
 only the extern one can be connect with the outside。But when in 
 PASSIVE_LOCAL_DATA_CONNECTION_MODE, FTPClient may be select the intra Ip, So 
 it didn't work。
 So I change code like this, it can work normally by the specific ip.
 Code:
 In FTPClient._openDataConnection_(String command, String arg)，line 761 change 
 as bellow:
 socket = _socketFactory_.createSocket();
 
 // add begin
 // local as client, transfer data must use the appointed local host
 socket.bind(new InetSocketAddress(getHostAddress(), 0));
 // add end
 After log in success,User can set the ip which he want to use by call the 
 method in FTPClient:
 setActiveExternalIPAddress(String ip); 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (NET-468) Request for native support for socks proxy routing with Commons net FTP

2012-07-02 Thread Bogdan Drozdowski (JIRA)

[
https://issues.apache.org/jira/browse/NET-468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Bogdan Drozdowski updated NET-468:
--

Attachment: sockclient-proxy2.diff

OK, here you go. Sockets have no getter methods for proxies and I don't want a
test case to depend on something external (like a proxy server running on some
host+port), so this simple test case focuses on checking if set+get actually
work. Test is passed.

Request for native support for socks proxy routing with Commons net FTP
---

[jira] [Updated] (NET-468) Request for native support for socks proxy routing with Commons net FTP

2012-07-02 Thread Bogdan Drozdowski (JIRA)

[
https://issues.apache.org/jira/browse/NET-468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Bogdan Drozdowski updated NET-468:
--

Attachment: (was: sockclient-proxy.diff)

Request for native support for socks proxy routing with Commons net FTP
---

[jira] [Updated] (NET-468) Request for native support for socks proxy routing with Commons net FTP

2012-07-01 Thread Bogdan Drozdowski (JIRA)

[
https://issues.apache.org/jira/browse/NET-468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Bogdan Drozdowski updated NET-468:
--

Attachment: sockclient-proxy.diff

Native proxy support is already present - you can install your own
SocketFactory which creates Sockets with Proxy support. The attached file,
sockclient-proxy.diff, makes this easier - when you set a Proxy, it creates and
installs a new DefaultSocketFactory, which now has easy Proxy support (also
thanks to this patch).
Call setSocketFactory() for now, until this patch is included in the
distribution (if it will be).

Request for native support for socks proxy routing with Commons net FTP
---

[jira] [Commented] (NET-470) DataConnection-Socket hangs on InputStream.read()

2012-07-01 Thread Bogdan Drozdowski (JIRA)


[ 
https://issues.apache.org/jira/browse/NET-470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13404727#comment-13404727
 ] 

Bogdan Drozdowski commented on NET-470:
---

Does it work with plaintext (no SSL) connections? Perhaps you have the same 
problem as in NET-408, but your server doesn't break the connection with an 
error?

 DataConnection-Socket hangs on InputStream.read()
 -

 Key: NET-470
 URL: https://issues.apache.org/jira/browse/NET-470
 Project: Commons Net
  Issue Type: Bug
  Components: FTP
Affects Versions: 3.0, 3.0.1, 3.1
 Environment: Windows 7 (x86), Netbeans 7, JDK 1.6 and JDK 1.7
Reporter: Alexander Schuetz
 Attachments: examplePatch.diff


 I'm using ftps (SSL/implicit) and passive mode. connect(), login() and cwd() 
 commands work well.
 But if I have to open a data connection (for example for LIST) the socket is 
 opened successfully using one of the desired dataports. The underlying 
 InputStream is created as well without any Exception.
 But then every attempt to read from the InputStream will eventually time out 
 or hang forever (depending on the DataTimeout-value).
 If I use the FileZilla client, everything works successfully and fast. 
 FileZilla issues the following commands:
 {color:blue}
 {{C: SYST}}
 {{A: 215 UNIX Type: L8}}
 {{C: FEAT}}
 {{A: 211-Extensions supported}}
 {{A:  SIZE}}
 {{A:  REST}}
 {{A:  MDTM}}
 {{A:  MFMT MMDDHHMMSS filename}}
 {{A:  MDTM MMDDHHMMSS filename}}
 {{A:  MDTM MMDDHHMMSS[+-TZ] filename}}
 {{A:  XCRC filename}}
 {{A:  XMD5 filename}}
 {{A:  AUTH TLS}}
 {{A:  AUTH SSL}}
 {{A:  MODE Z}}
 {{A:  PBSZ}}
 {{A:  PROT}}
 {{A: 211 End of FEAT}}
 {{C: USER }}
 {{A: 331 Password required for }}
 {{C: PASS }}
 {{A: 230 User  logged in}}
 {{C: PBSZ 0}}
 {{A: 200 PBSZ 0 successful}}
 {{C: PROT P}}
 {{A: 200 Data connection set to: Private}}
 {{C: TYPE I}}
 {{A: 200 TYPE set to BINARY}}
 {{C: PASV}}
 {{A: 227 Entering passive mode (217,70,161,93,39,15)}}
 {{C: LIST}}
 {{A: 150 Opening ASCII mode data connection}}
 {{A: 226 Directory send OK}}
 {color}
 Issueing the commands PBSZ 0 and PROT P before and calling 
 enterLocalPassiveMode() and setFileType(FTP.BINARY_FILE_TYPE) will produce 
 the same commandsequence (without SYST and FEAT), but with the error 
 described above.
   
 On top of that: disconnect() will block forever, originating from 
 socket.close() which is blocking. The only way to avoid this is calling 
 logout() (even if login() wasn't issued). Then disconnect will return as 
 expected.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (NET-465) FTPClient setSendBufferSize and setReceiveBufferSize on data socket

2012-06-27 Thread Bogdan Drozdowski (JIRA)


 [ 
https://issues.apache.org/jira/browse/NET-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bogdan Drozdowski updated NET-465:
--

Attachment: ftp-bufsize.diff

The buffer size already was for the data connections, but it was set only on 
the buffered input and output streams, not on the sockets. The attached file, 
ftp-bufsize.diff, fixes this. Now if the buffer size is greater than zero, it 
is used both on the streams and the sockets. If the buffer size is set to 0 or 
less, the defaults are used (nothing is set on the sockets and the buffered 
streams use the default size).

 FTPClient setSendBufferSize and setReceiveBufferSize on data socket
 ---

 Key: NET-465
 URL: https://issues.apache.org/jira/browse/NET-465
 Project: Commons Net
  Issue Type: Bug
  Components: FTP
Affects Versions: 3.1
 Environment: All
Reporter: Jim Kerwood
 Attachments: ftp-bufsize.diff

   Original Estimate: 0.25h
  Remaining Estimate: 0.25h

 When sending large files the need to set the send and receive buffer sizes on 
 the data socket is much more important than the command socket.  Please 
 either give 2 more setters or make the setters set the data socket and leave 
 the command socket alone.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (NET-463) Does it make sense for NET classes to be Serializable?

2012-06-27 Thread Bogdan Drozdowski (JIRA)

[
https://issues.apache.org/jira/browse/NET-463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13402329#comment-13402329
]

Bogdan Drozdowski commented on NET-463:
---

Having classes Serializable is useful when you have to use them remotely (e.g.
through RMI, CORBA, EJB or similar means), because the objects are passed by
reference when they're serializable (instead of being passed by value, which
may be expensive). An EJB or RMI server could be a provider/factory of, say,
SocekClient instances, that callers wish to use. I don't know if a real-life
example like this could ever happen, but it's certainly one use for
serializability.

Does it make sense for NET classes to be Serializable?
--

Key: NET-463
URL: https://issues.apache.org/jira/browse/NET-463
Project: Commons Net
Issue Type: Bug
Reporter: Sebb

A few of the NET classes currently implement Serializable.
However, it's doubtful that serialization would actually work.
There are no unit tests.
Also, what is the use-case for it?
Can we drop the Serializable references?
The classes that implement Serializable currently are:
ftp.FTPFile
ntp.TimeStamp
util.ListenerList (contains non-serialisable field of type
CopyOnWriteArrayList)
ProtocolCommandSupport

[jira] [Commented] (NET-449) listFiles bug with folder that begins with -

2012-06-27 Thread Bogdan Drozdowski (JIRA)


[ 
https://issues.apache.org/jira/browse/NET-449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13402337#comment-13402337
 ] 

Bogdan Drozdowski commented on NET-449:
---

Some servers (most?) probably pass the argument to the ls command, hence the 
results. One workaround is provided in the listing above - use absolute paths. 
Another workaround is: if the path to be listed starts with a dash, prepend a 
./ to it, but this will work only on Unix-like servers or those which 
implement TVFS. So, there would be need to call SYST and FEAT on every connect, 
but what if the server doesn't support FEAT, TVFS or SYST (or replies that it's 
not a Unix)?
I think it should be the user who should decide to use any of these workarounds 
(they can do it themselves), but the documentation (at least the Javadoc 
comment) should mention this case.

 listFiles bug with folder that begins with -
 --

 Key: NET-449
 URL: https://issues.apache.org/jira/browse/NET-449
 Project: Commons Net
  Issue Type: Bug
  Components: FTP
Affects Versions: 3.1
Reporter: Stéphane Verger

 FTP Server status:
 {code}
 root@xxx-srv:/data/Library# tree -A
 .
 ├── -dash
 │   ├── -dash.txt
 │   ├── file1.txt
 │   └── file2.txt
 └── test
 ├── file2.txt
 └── file.txt
 {code}
 Test code:
 {code} 
 final org.apache.commons.net.ftp.FTPClient ftp = new 
 org.apache.commons.net.ftp.FTPClient();
   ftp.connect(host, port);
   ftp.login(login, pwd);
   
   System.out.println(PWD:  + ftp.printWorkingDirectory());
   final FTPFile[] listFiles = ftp.listFiles();
   for (int i = 0; i  listFiles.length; i++) {
   System.out.println([ + i + ]  + listFiles[i]);
   }
   
   System.out.println(Files in /-dash);
   final FTPFile[] listFiles2 = ftp.listFiles(/-dash);
   for (int i = 0; i  listFiles2.length; i++) {
   System.out.println([ + i + ]  + listFiles2[i]);
   }
   
   System.out.println(Files in -dash);
   final FTPFile[] listFiles3 = ftp.listFiles(-dash);
   for (int i = 0; i  listFiles3.length; i++) {
   System.out.println([ + i + ]  + listFiles3[i]);
   }
 {code} 
 results:
 {code} 
 PWD: /
 [0] -dash
 [1] test
 Files in /-dash
 [0] -dash.txt
 [1] file1.txt
 [2] file2.txt
 Files in -dash
 [0] -dash
 [1] .
 [2] ..
 [3] test
 {code} 
 When listing -dash, it list the current directory instead of the 
 destination one.
 If I do the same test with the folder test, this time it works as expected.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (NET-419) Not possible to call FTPClient.abort() method correctly

2011-09-18 Thread Bogdan Drozdowski (JIRA)


 [ 
https://issues.apache.org/jira/browse/NET-419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bogdan Drozdowski updated NET-419:
--

Attachment: ftp-synchro.diff

The attached file, ftp-synchro.diff, synchronizes all the uses of the control 
socket (and its associated readers and writers). This should help in avoiding 
the incorrect replies to commands.
It also introduces a boolean that tells if the user has called abort(). 
Currently all it does is skipping the now-perhaps-unnecessary replies on the 
control channel after aborting a transfer.
This patch works for me: the FTP client does not lock because of 
synchronization and calling abor() on a separate Thread returns 226 Abort 
successful and the file is not totally transferred. It needs a re-think, 
though: do we need to skip the additional answers, so the user can read them? 
Perhaps something else should be done?
To abort a transfer as soon as possible, abor() should be called, followed by 
closing the Input/OutputStream connected to the transfer. One may call 
interrupt() on the transfer Thread (after this, read()/write() should throw an 
InterruptedException, which should propagate all the way up to the code calling 
the FTP client), but someone noticed that it may not always work. On the other 
hand, closing the stream should always work.

 Not possible to call FTPClient.abort() method correctly
 ---

 Key: NET-419
 URL: https://issues.apache.org/jira/browse/NET-419
 Project: Commons Net
  Issue Type: Bug
  Components: FTP
Affects Versions: 3.0
 Environment: java version 1.6.0_26
 Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
 Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)
 Linux cattie 2.6.38-10-generic #46-Ubuntu SMP Tue Jun 28 15:07:17 UTC 2011 
 x86_64 x86_64 x86_64 GNU/Linux
Reporter: Tomas Mysik
 Attachments: ftp-synchro.diff


 Unfortunately, it seems that there are difficulties of using FTPClient.abort()
 method [1][2]. Also, it is really not clear how the abort() method should be
 called/used at all - if from another thread (as I would expect) then there is 
 a problem with
 thread-safety: FTPClient itself is not thread-safe so it means that some
 custom lock/monitor must be used; but this lock will prevent calling abort() 
 on
 the FTPClient while it is downloading/uploading file since file 
 upload/download
 itself is blocking...
 If I'm wrong and the abort() method works then an example in Javadoc would be 
 more than welcome.
 Thanks a lot.
 [1] 
 http://apache-commons.680414.n4.nabble.com/Net-FTPClient-abort-problem-td739542.html
 [2] http://www.tikalk.com/java/forums/apache-ftp-client-abort-transfer

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (NET-249) FtpClient hangs 20 minutes in FTPClient.completePendingCommand from retrieveFile or listFiles

2011-09-18 Thread Bogdan Drozdowski (JIRA)


[ 
https://issues.apache.org/jira/browse/NET-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13107411#comment-13107411
 ] 

Bogdan Drozdowski commented on NET-249:
---

Perhaps timing and synchronization plays a role here? Try the ftp-synchro.diff 
patch from NET-419 and let us know.

 FtpClient hangs 20 minutes in FTPClient.completePendingCommand from 
 retrieveFile or listFiles
 -

 Key: NET-249
 URL: https://issues.apache.org/jira/browse/NET-249
 Project: Commons Net
  Issue Type: Bug
  Components: FTP
Affects Versions: 1.4, 2.0
 Environment: Client and Server running on Solaris 9
Reporter: David Tavoularis

 I have a Ftp Client with several connections in multi-thread that connects to 
 a remote Ftp Server to list files and download new ones.
 After 3 minutes of runtime, I get a 20-minute timeout for all running Ftp 
 connections.
 Here are the logs for 1 thread :
 {noformat}
 20090114 142216 (Command Sent Message): PASV
 20090114 142216 (Reply Received Message): 227 Entering Passive Mode 
 (10,250,10,116,224,172)
 20090114 142216 (Command Sent Message): LIST /Dir1/Dir2/Dir3
 20090114 142216 (Reply Received Message): 150 Opening BINARY mode data 
 connection for /bin/ls.
 20090114 142216 (Reply Received Message): 226 Transfer complete.
 20090114 142216 (Command Sent Message): PASV
 20090114 142216 (Reply Received Message): 227 Entering Passive Mode 
 (10,250,10,116,138,240)
 20090114 142216 (Command Sent Message): RETR /Dir1/Dir2/Dir3/File1
 20090114 142216 (Reply Received Message): 150 Opening BINARY mode data 
 connection for /Dir1/Dir2/Dir3/File1 (12364 bytes).
 *** 20 minutes without any message ***
 20090114 144216 (Reply Received Message): 426 Data connection: Interrupted 
 system call.
 20090114 144216 (Command Sent Message): PASV
 20090114 144216 (Reply Received Message): 227 Entering Passive Mode 
 (10,250,10,116,109,169)
 20090114 144216 (Command Sent Message): RETR /Dir1/Dir2/Dir3/File1
 20090114 144216 (Reply Received Message): 150 Opening BINARY mode data 
 connection for /Dir1/Dir2/Dir3/File2 (12387 bytes).
 20090114 144216 (Reply Received Message): 226 Transfer complete.
 {noformat}
 Here are the logs for another thread :
 {noformat}
 20090114 142216 (Command Sent Message): PASV
 20090114 142216 (Reply Received Message): 227 Entering Passive Mode 
 (10,250,10,116,174,233)
 20090114 142216 (Command Sent Message): RETR /DirA/DirB/DirC/FileA
 20090114 142216 (Reply Received Message): 150 Opening BINARY mode data 
 connection for /DirA/DirB/DirC/FileA (14209 bytes).
 20090114 142216 (Reply Received Message): 226 Transfer complete.
 20090114 142216 (Command Sent Message): PASV
 20090114 142216 (Reply Received Message): 227 Entering Passive Mode 
 (10,250,10,116,202,81)
 20090114 142216 (Command Sent Message): LIST /DirA/DirB/DirD
 20090114 142216 (Reply Received Message): 150 Opening BINARY mode data 
 connection for /bin/ls.
 *** 20 minutes without any message ***
 20090114 144216 (Reply Received Message): 426 Data connection: Interrupted 
 system call.
 20090114 144216 (Command Sent Message): PASV
 20090114 144216 (Reply Received Message): 227 Entering Passive Mode 
 (10,250,10,116,11,16)
 20090114 144216 (Command Sent Message): RETR /DirA/DirB/DirD/FileB
 20090114 144216 (Reply Received Message): 150 Opening BINARY mode data 
 connection for /DirA/DirB/DirD/FileB (14145 bytes).
 {noformat}
 So it happens during LIST or during RETR command.
 The issue is always reproducible when connecting to this Ftp server.
 What is the meaning of the error message 426 Data connection: Interrupted 
 system call. ?
 Here are the stack-traces where the FtpClient is blocked during 20 minutes.
 For 1st connection :
 {noformat}
 Stack 30 - Wed Jan 14 14:40:00 CET 2009
 FTPMediationTask prio=3 tid=0x00aac800 nid=0x156 runnable 
 [0x6877e000..0x6877fb70]
java.lang.Thread.State: RUNNABLE
   at java.net.SocketInputStream.socketRead0(Native Method)
   at java.net.SocketInputStream.read(SocketInputStream.java:129)
   at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:264)
   at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306)
   at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158)
   - locked 0x8fc23880 (a java.io.InputStreamReader)
   at java.io.InputStreamReader.read(InputStreamReader.java:167)
   at java.io.BufferedReader.fill(BufferedReader.java:136)
   at java.io.BufferedReader.readLine(BufferedReader.java:299)
   - locked 0x8fc23880 (a java.io.InputStreamReader)
   at java.io.BufferedReader.readLine(BufferedReader.java:362)
   at org.apache.commons.net.ftp.FTP.__getReply(FTP.java:294)
   at org.apache.commons.net.ftp.FTP.getReply(FTP.java:619)
   at

[jira] [Commented] (NET-419) Not possible to call FTPClient.abort() method correctly

2011-09-03 Thread Bogdan Drozdowski (JIRA)


[ 
https://issues.apache.org/jira/browse/NET-419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13096681#comment-13096681
 ] 

Bogdan Drozdowski commented on NET-419:
---

 No need to ping us. We see your message. We may not reply immediately, but 
your issue is still open.
 The problem is that it's not that easy just to provide thread-safety. If the 
methods are synchronized, you won't be able to call abort() when another method 
is executing (like retrieveFile()).
 Perhaps just command sending should be synchronized (to synchronize the 
input/output buffers), but that won't always solve the problem, because some 
commands (like file send/retrieve) have two replies and the client needs to 
wait for the second one, so it needs to be in the synchronized block while the 
operation you want to abort is being performed. Right now we dont' have 
synchronized blocks, so you can call abort() at any time (and mostly it will 
work). If we had everything synchronized, you wouldn't be able to call abort() 
during the operation at all. So even if the current solution is not perfect, 
the synchronized solution is even worse. This needs a re-think of what should 
be done.

 Not possible to call FTPClient.abort() method correctly
 ---

 Key: NET-419
 URL: https://issues.apache.org/jira/browse/NET-419
 Project: Commons Net
  Issue Type: Bug
  Components: FTP
Affects Versions: 3.0
 Environment: java version 1.6.0_26
 Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
 Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)
 Linux cattie 2.6.38-10-generic #46-Ubuntu SMP Tue Jun 28 15:07:17 UTC 2011 
 x86_64 x86_64 x86_64 GNU/Linux
Reporter: Tomas Mysik

 Unfortunately, it seems that there are difficulties of using FTPClient.abort()
 method [1][2]. Also, it is really not clear how the abort() method should be
 called/used at all - if from another thread (as I would expect) then there is 
 a problem with
 thread-safety: FTPClient itself is not thread-safe so it means that some
 custom lock/monitor must be used; but this lock will prevent calling abort() 
 on
 the FTPClient while it is downloading/uploading file since file 
 upload/download
 itself is blocking...
 If I'm wrong and the abort() method works then an example in Javadoc would be 
 more than welcome.
 Thanks a lot.
 [1] 
 http://apache-commons.680414.n4.nabble.com/Net-FTPClient-abort-problem-td739542.html
 [2] http://www.tikalk.com/java/forums/apache-ftp-client-abort-transfer

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (NET-408) problem connecting to ProFTPD with FTPES

2011-07-25 Thread Bogdan Drozdowski (JIRA)


 [ 
https://issues.apache.org/jira/browse/NET-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bogdan Drozdowski updated NET-408:
--

Attachment: BCFTPSClient.java

This is the bouncycastle-based FTPSClient. Unfortunately, it doesn't work for 
me (still session not reused error). Apparently, the notifySessionID doesn't 
make the TlsClient use this session ID (or I'm doing something wrong).

The code is a mess - some lines just commented-out, many now-useless methods 
not removed, active-only mode supported. I didn't clean it up, because it 
doesn't work anyway (for me). If you like it, you can use it. If it works for 
you, let us know. Compile against bcprov-jdk16-XXX.jar.

 problem connecting to ProFTPD with FTPES
 

 Key: NET-408
 URL: https://issues.apache.org/jira/browse/NET-408
 Project: Commons Net
  Issue Type: Bug
  Components: FTP
Affects Versions: 2.2, 3.0
 Environment: ProFTPD 1.3.3d on SUSE Linux Enterprise Server 10.1 
 32bit, Kernel 2.6.16.46-0.12-default (config file attached)
 ProFTPD 1.3.3d on OpenSUSE 64bit Linux 2.6.34.8-0.2-desktop
 Java 1.5
Reporter: Michael Voigt
 Attachments: BCFTPSClient.java, ftpes.jpg, proftpd.conf


 I have a problem with the FTPClient connecting to a ProFTPD server.
 If the server uses the configuration option TLSProtocol TLSv1, I
 cannot connect to it at all. I recieve the following error message:
 - javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection
 On the server side I see in the log:
 unable to accept TLS connection: protocol error:
 -  (1) error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert
 certificate unknown
 - TLS/TLS-C negotiation failed on control channel
 If the server uses the configuration option TLSProtocol SSLv23, I
 can connect to it but I cant transfer any files. In the server log I
 see:
 - starting TLS negotiation on data connection
 - TLSv1/SSLv3 renegotiation accepted, using cipher RC4-MD5 (128 bits)
 - client did not reuse SSL session, rejecting data connection (see
 TLSOption NoSessionReuseRequired)
 - unable to open data connection: TLS negotiation failed
 If I add the NoSessionReuseRequired parameter to the ProFTPD config
 everything works fine.
 Here is my code:
FTPClient ftpClient = new FTPClient();
ftpClient = new FTPSClient(TLS);
// this throws an exception with TLSProtocol TLSv1
ftpClient.connect(host, port);
int reply = ftpClient.getReplyCode();
if (!FTPReply.isPositiveCompletion(reply)) {
ftpClient.disconnect();
log.error(The FTP Server did not return a positive 
 completion reply!);
throw new 
 FtpTransferException(ECCUtils.ERROR_FTP_CONNECTION);
}
boolean loginSuccessful = ftpClient.login(userName, password);
if (!loginSuccessful) {
log.error(Login to the FTP Server failed! The 
 credentials are not valid.);
throw new 
 FtpTransferException(ECCUtils.ERROR_FTP_LOGIN);
}
ftpClient.execPBSZ(0);
ftpClient.execPROT(P);
boolean success = ftpClient.storeFile(fileName, fis);
if (!success) {
// this is false if NoSessionReuseRequired is not set
}
 Now my question is if it is generally possible to connect to a server
 with TLSProtocol TLSv1 or TLSProtocol SSLv23 without the
 NoSessionReuseRequired parameter? Could someone provide a piece of
 example code for this?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (NET-408) problem connecting to ProFTPD with FTPES

2011-07-25 Thread Bogdan Drozdowski (JIRA)


 [ 
https://issues.apache.org/jira/browse/NET-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bogdan Drozdowski updated NET-408:
--

Attachment: PTFTPSClient.java

The attached PTFTPSClient is the PureTLS-based FTPSClient. It uses the 
host/port pair (whatever provided, just use unique for each control connection 
and the control connection's host/port for data connections) to identify 
connections.

It doesn't work for me (I get Not a PrintableString or IA5String exceptions), 
but it may be my server's certificate's fault, so you may try it.

This code also is a mess - the host/port pairs (that identify sessions) are 
hardcoded, some now-useless methods are not removed. It's more like some base 
test code, to be rebuilt if works. If you like it, use it. If it works for you, 
let us know.

 problem connecting to ProFTPD with FTPES
 

 Key: NET-408
 URL: https://issues.apache.org/jira/browse/NET-408
 Project: Commons Net
  Issue Type: Bug
  Components: FTP
Affects Versions: 2.2, 3.0
 Environment: ProFTPD 1.3.3d on SUSE Linux Enterprise Server 10.1 
 32bit, Kernel 2.6.16.46-0.12-default (config file attached)
 ProFTPD 1.3.3d on OpenSUSE 64bit Linux 2.6.34.8-0.2-desktop
 Java 1.5
Reporter: Michael Voigt
 Attachments: BCFTPSClient.java, PTFTPSClient.java, ftpes.jpg, 
 proftpd.conf


 I have a problem with the FTPClient connecting to a ProFTPD server.
 If the server uses the configuration option TLSProtocol TLSv1, I
 cannot connect to it at all. I recieve the following error message:
 - javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection
 On the server side I see in the log:
 unable to accept TLS connection: protocol error:
 -  (1) error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert
 certificate unknown
 - TLS/TLS-C negotiation failed on control channel
 If the server uses the configuration option TLSProtocol SSLv23, I
 can connect to it but I cant transfer any files. In the server log I
 see:
 - starting TLS negotiation on data connection
 - TLSv1/SSLv3 renegotiation accepted, using cipher RC4-MD5 (128 bits)
 - client did not reuse SSL session, rejecting data connection (see
 TLSOption NoSessionReuseRequired)
 - unable to open data connection: TLS negotiation failed
 If I add the NoSessionReuseRequired parameter to the ProFTPD config
 everything works fine.
 Here is my code:
FTPClient ftpClient = new FTPClient();
ftpClient = new FTPSClient(TLS);
// this throws an exception with TLSProtocol TLSv1
ftpClient.connect(host, port);
int reply = ftpClient.getReplyCode();
if (!FTPReply.isPositiveCompletion(reply)) {
ftpClient.disconnect();
log.error(The FTP Server did not return a positive 
 completion reply!);
throw new 
 FtpTransferException(ECCUtils.ERROR_FTP_CONNECTION);
}
boolean loginSuccessful = ftpClient.login(userName, password);
if (!loginSuccessful) {
log.error(Login to the FTP Server failed! The 
 credentials are not valid.);
throw new 
 FtpTransferException(ECCUtils.ERROR_FTP_LOGIN);
}
ftpClient.execPBSZ(0);
ftpClient.execPROT(P);
boolean success = ftpClient.storeFile(fileName, fis);
if (!success) {
// this is false if NoSessionReuseRequired is not set
}
 Now my question is if it is generally possible to connect to a server
 with TLSProtocol TLSv1 or TLSProtocol SSLv23 without the
 NoSessionReuseRequired parameter? Could someone provide a piece of
 example code for this?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Issue Comment Edited] (NET-408) problem connecting to ProFTPD with FTPES

2011-07-25 Thread Bogdan Drozdowski (JIRA)


[ 
https://issues.apache.org/jira/browse/NET-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13070392#comment-13070392
 ] 

Bogdan Drozdowski edited comment on NET-408 at 7/25/11 9:37 AM:


The attached BCFTPSClient is the bouncycastle-based FTPSClient. Unfortunately, 
it doesn't work for me (still session not reused error). Apparently, the 
notifySessionID doesn't make the TlsClient use this session ID (or I'm doing 
something wrong).

The code is a mess - some lines just commented-out, many now-useless methods 
not removed, active-only mode supported. I didn't clean it up, because it 
doesn't work anyway (for me). If you like it, you can use it. If it works for 
you, let us know. Compile against bcprov-jdk16-XXX.jar.

  was (Author: bogdro):
This is the bouncycastle-based FTPSClient. Unfortunately, it doesn't work 
for me (still session not reused error). Apparently, the notifySessionID 
doesn't make the TlsClient use this session ID (or I'm doing something wrong).

The code is a mess - some lines just commented-out, many now-useless methods 
not removed, active-only mode supported. I didn't clean it up, because it 
doesn't work anyway (for me). If you like it, you can use it. If it works for 
you, let us know. Compile against bcprov-jdk16-XXX.jar.
  
 problem connecting to ProFTPD with FTPES
 

 Key: NET-408
 URL: https://issues.apache.org/jira/browse/NET-408
 Project: Commons Net
  Issue Type: Bug
  Components: FTP
Affects Versions: 2.2, 3.0
 Environment: ProFTPD 1.3.3d on SUSE Linux Enterprise Server 10.1 
 32bit, Kernel 2.6.16.46-0.12-default (config file attached)
 ProFTPD 1.3.3d on OpenSUSE 64bit Linux 2.6.34.8-0.2-desktop
 Java 1.5
Reporter: Michael Voigt
 Attachments: BCFTPSClient.java, PTFTPSClient.java, ftpes.jpg, 
 proftpd.conf


 I have a problem with the FTPClient connecting to a ProFTPD server.
 If the server uses the configuration option TLSProtocol TLSv1, I
 cannot connect to it at all. I recieve the following error message:
 - javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection
 On the server side I see in the log:
 unable to accept TLS connection: protocol error:
 -  (1) error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert
 certificate unknown
 - TLS/TLS-C negotiation failed on control channel
 If the server uses the configuration option TLSProtocol SSLv23, I
 can connect to it but I cant transfer any files. In the server log I
 see:
 - starting TLS negotiation on data connection
 - TLSv1/SSLv3 renegotiation accepted, using cipher RC4-MD5 (128 bits)
 - client did not reuse SSL session, rejecting data connection (see
 TLSOption NoSessionReuseRequired)
 - unable to open data connection: TLS negotiation failed
 If I add the NoSessionReuseRequired parameter to the ProFTPD config
 everything works fine.
 Here is my code:
FTPClient ftpClient = new FTPClient();
ftpClient = new FTPSClient(TLS);
// this throws an exception with TLSProtocol TLSv1
ftpClient.connect(host, port);
int reply = ftpClient.getReplyCode();
if (!FTPReply.isPositiveCompletion(reply)) {
ftpClient.disconnect();
log.error(The FTP Server did not return a positive 
 completion reply!);
throw new 
 FtpTransferException(ECCUtils.ERROR_FTP_CONNECTION);
}
boolean loginSuccessful = ftpClient.login(userName, password);
if (!loginSuccessful) {
log.error(Login to the FTP Server failed! The 
 credentials are not valid.);
throw new 
 FtpTransferException(ECCUtils.ERROR_FTP_LOGIN);
}
ftpClient.execPBSZ(0);
ftpClient.execPROT(P);
boolean success = ftpClient.storeFile(fileName, fis);
if (!success) {
// this is false if NoSessionReuseRequired is not set
}
 Now my question is if it is generally possible to connect to a server
 with TLSProtocol TLSv1 or TLSProtocol SSLv23 without the
 NoSessionReuseRequired parameter? Could someone provide a piece of
 example code for this?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (NET-408) problem connecting to ProFTPD with FTPES

2011-06-29 Thread Bogdan Drozdowski (JIRA)


[ 
https://issues.apache.org/jira/browse/NET-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13057371#comment-13057371
 ] 

Bogdan Drozdowski commented on NET-408:
---

Short-time fix - probably not. As you can see, it's just not that easy. But if 
you find an open-source FTP program in Java that works with your ProFTPd, it 
might help us create something similar in Commons-Net, so let us know as soon 
as you find something.

@David: Yes, TlsProtocolHandler connects TlsClients which have something to do 
with session IDs, so this also might be an option. But, as you say, it's not a 
drop-in. This would also require a partial or complete re-write of the 
FTPSClient. It might be easier to use than PureTLS. Not to mention that it is 
more maintained and up-to-date (PureTLS's ChangLog ends on the year 2002). 
Unfortunately, still a new dependency for Commons-Net.

 problem connecting to ProFTPD with FTPES
 

 Key: NET-408
 URL: https://issues.apache.org/jira/browse/NET-408
 Project: Commons Net
  Issue Type: Bug
  Components: FTP
Affects Versions: 2.2, 3.0
 Environment: ProFTPD 1.3.3d on SUSE Linux Enterprise Server 10.1 
 32bit, Kernel 2.6.16.46-0.12-default (config file attached)
 ProFTPD 1.3.3d on OpenSUSE 64bit Linux 2.6.34.8-0.2-desktop
 Java 1.5
Reporter: Michael Voigt
 Attachments: ftpes.jpg, proftpd.conf


 I have a problem with the FTPClient connecting to a ProFTPD server.
 If the server uses the configuration option TLSProtocol TLSv1, I
 cannot connect to it at all. I recieve the following error message:
 - javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection
 On the server side I see in the log:
 unable to accept TLS connection: protocol error:
 -  (1) error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert
 certificate unknown
 - TLS/TLS-C negotiation failed on control channel
 If the server uses the configuration option TLSProtocol SSLv23, I
 can connect to it but I cant transfer any files. In the server log I
 see:
 - starting TLS negotiation on data connection
 - TLSv1/SSLv3 renegotiation accepted, using cipher RC4-MD5 (128 bits)
 - client did not reuse SSL session, rejecting data connection (see
 TLSOption NoSessionReuseRequired)
 - unable to open data connection: TLS negotiation failed
 If I add the NoSessionReuseRequired parameter to the ProFTPD config
 everything works fine.
 Here is my code:
FTPClient ftpClient = new FTPClient();
ftpClient = new FTPSClient(TLS);
// this throws an exception with TLSProtocol TLSv1
ftpClient.connect(host, port);
int reply = ftpClient.getReplyCode();
if (!FTPReply.isPositiveCompletion(reply)) {
ftpClient.disconnect();
log.error(The FTP Server did not return a positive 
 completion reply!);
throw new 
 FtpTransferException(ECCUtils.ERROR_FTP_CONNECTION);
}
boolean loginSuccessful = ftpClient.login(userName, password);
if (!loginSuccessful) {
log.error(Login to the FTP Server failed! The 
 credentials are not valid.);
throw new 
 FtpTransferException(ECCUtils.ERROR_FTP_LOGIN);
}
ftpClient.execPBSZ(0);
ftpClient.execPROT(P);
boolean success = ftpClient.storeFile(fileName, fis);
if (!success) {
// this is false if NoSessionReuseRequired is not set
}
 Now my question is if it is generally possible to connect to a server
 with TLSProtocol TLSv1 or TLSProtocol SSLv23 without the
 NoSessionReuseRequired parameter? Could someone provide a piece of
 example code for this?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (NET-408) problem connecting to ProFTPD with FTPES

2011-06-25 Thread Bogdan Drozdowski (JIRA)


[ 
https://issues.apache.org/jira/browse/NET-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13054937#comment-13054937
 ] 

Bogdan Drozdowski commented on NET-408:
---

I finally got some time to look at this. I confirm the problem exists when 
connecting by IP in both active and passive mode to ProFTPd 1.3.3e. I confirm 
the sessions are different for the control and data connections (as per 
.toString()) despite using one SSLContext everywhere. Disabling session 
creating in server sockets or disabling client mode in them doesn't help.

I looked more closely at the JSSE Reference and yes, you can reuse sessions, 
but the only way you can do it is by passing the same host and port to the 
SSLEngine creation methods. These don't need to be the actual host and port 
you're connecting to (luckily) - they're just a marker or connection 
identifier. The first bad news is that these are just a hint, so the 
implementation might just as well ignore these and always create new SSL 
sessions. The second bad news is that you can't use an SSLEngine anywhere. You 
can't create contexts or sockets with it. The only thing you can do is creating 
your own subset of TLS implementation for your needs, just like in the example 
in the JSSE Reference Guide - you check message types, wrap and unwrap them 
etc. Just creating an SSLEngine from an SSLContext doesn't work, you have to 
use it.

Now better news that I've found: the PureTLS library 
(http://www.rtfm.com/puretls/) seems to do it in an easier way - you specify 
the host and port in the constructors and they're used to find sessions, so 
re-using sessions looks possible. The drawback is that the whole FTPSClient 
would have to be re-written to use this library and a new project dependency 
would have to be introduced, not to mention that PureTLS may not be as secure 
as the original SSL code in the JRE. There also is ftp4j, but it doesn't semm 
to do more that the Commons-Net FTP Client in terms of SSL.

The whole SSL stuff is so wrapped in Java that you can't access the details and 
you don't have full control over what's being done unless you write your own 
implementation.

 problem connecting to ProFTPD with FTPES
 

 Key: NET-408
 URL: https://issues.apache.org/jira/browse/NET-408
 Project: Commons Net
  Issue Type: Bug
  Components: FTP
Affects Versions: 2.2, 3.0
 Environment: ProFTPD 1.3.3d on SUSE Linux Enterprise Server 10.1 
 32bit, Kernel 2.6.16.46-0.12-default (config file attached)
 ProFTPD 1.3.3d on OpenSUSE 64bit Linux 2.6.34.8-0.2-desktop
 Java 1.5
Reporter: Michael Voigt
 Attachments: ftpes.jpg, proftpd.conf


 I have a problem with the FTPClient connecting to a ProFTPD server.
 If the server uses the configuration option TLSProtocol TLSv1, I
 cannot connect to it at all. I recieve the following error message:
 - javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection
 On the server side I see in the log:
 unable to accept TLS connection: protocol error:
 -  (1) error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert
 certificate unknown
 - TLS/TLS-C negotiation failed on control channel
 If the server uses the configuration option TLSProtocol SSLv23, I
 can connect to it but I cant transfer any files. In the server log I
 see:
 - starting TLS negotiation on data connection
 - TLSv1/SSLv3 renegotiation accepted, using cipher RC4-MD5 (128 bits)
 - client did not reuse SSL session, rejecting data connection (see
 TLSOption NoSessionReuseRequired)
 - unable to open data connection: TLS negotiation failed
 If I add the NoSessionReuseRequired parameter to the ProFTPD config
 everything works fine.
 Here is my code:
FTPClient ftpClient = new FTPClient();
ftpClient = new FTPSClient(TLS);
// this throws an exception with TLSProtocol TLSv1
ftpClient.connect(host, port);
int reply = ftpClient.getReplyCode();
if (!FTPReply.isPositiveCompletion(reply)) {
ftpClient.disconnect();
log.error(The FTP Server did not return a positive 
 completion reply!);
throw new 
 FtpTransferException(ECCUtils.ERROR_FTP_CONNECTION);
}
boolean loginSuccessful = ftpClient.login(userName, password);
if (!loginSuccessful) {
log.error(Login to the FTP Server failed! The 
 credentials are not valid.);
throw new 
 FtpTransferException(ECCUtils.ERROR_FTP_LOGIN);
}
ftpClient.execPBSZ(0);
ftpClient.execPROT(P);
boolean success = ftpClient.storeFile(fileName, fis);
if (!success) {
// this is false if

[jira] [Commented] (NET-408) problem connecting to ProFTPD with FTPES

2011-05-20 Thread Bogdan Drozdowski (JIRA)


[ 
https://issues.apache.org/jira/browse/NET-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13036928#comment-13036928
 ] 

Bogdan Drozdowski commented on NET-408:
---

Some say it's impossible 
(http://forums.oracle.com/forums/thread.jspa?messageID=9279689), but the Java 
SSE Reference guide says (JSSERefGuide.html#SSLSession) the SSLContext, 
SSLSession and SSLEngine can be used to re-use the session, with the help of 
SSLContext.getClientSessionContext(), or by just simply using the same 
SSLContext for the subsequent sockets. On some message board I've also read 
that altering the default behaviour (or adding this functionality) would 
eventually lead to re-implementing many, many classes.

Apache's FTPSClient seems to use the same SSLContext for the control and data 
connections, so this should work. But it may be the problem that the control 
channel connects to the host by name and the data channel connects using the IP 
address (because this is what the PASV command gives), so the addresses may not 
match and the session is not reused.

Michael, could you try connecting to the host by its IP address and checking if 
that works (that is, NoSessionReuseRequired is not required any more)? Could 
you also please check if data transfer works in ACTIVE mode?

 problem connecting to ProFTPD with FTPES
 

 Key: NET-408
 URL: https://issues.apache.org/jira/browse/NET-408
 Project: Commons Net
  Issue Type: Bug
  Components: FTP
Affects Versions: 2.2, 3.0
 Environment: ProFTPD 1.3.3d on SUSE Linux Enterprise Server 10.1 
 32bit, Kernel 2.6.16.46-0.12-default (config file attached)
 ProFTPD 1.3.3d on OpenSUSE 64bit Linux 2.6.34.8-0.2-desktop
 Java 1.5
Reporter: Michael Voigt
 Attachments: ftpes.jpg, proftpd.conf


 I have a problem with the FTPClient connecting to a ProFTPD server.
 If the server uses the configuration option TLSProtocol TLSv1, I
 cannot connect to it at all. I recieve the following error message:
 - javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection
 On the server side I see in the log:
 unable to accept TLS connection: protocol error:
 -  (1) error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert
 certificate unknown
 - TLS/TLS-C negotiation failed on control channel
 If the server uses the configuration option TLSProtocol SSLv23, I
 can connect to it but I cant transfer any files. In the server log I
 see:
 - starting TLS negotiation on data connection
 - TLSv1/SSLv3 renegotiation accepted, using cipher RC4-MD5 (128 bits)
 - client did not reuse SSL session, rejecting data connection (see
 TLSOption NoSessionReuseRequired)
 - unable to open data connection: TLS negotiation failed
 If I add the NoSessionReuseRequired parameter to the ProFTPD config
 everything works fine.
 Here is my code:
FTPClient ftpClient = new FTPClient();
ftpClient = new FTPSClient(TLS);
// this throws an exception with TLSProtocol TLSv1
ftpClient.connect(host, port);
int reply = ftpClient.getReplyCode();
if (!FTPReply.isPositiveCompletion(reply)) {
ftpClient.disconnect();
log.error(The FTP Server did not return a positive 
 completion reply!);
throw new 
 FtpTransferException(ECCUtils.ERROR_FTP_CONNECTION);
}
boolean loginSuccessful = ftpClient.login(userName, password);
if (!loginSuccessful) {
log.error(Login to the FTP Server failed! The 
 credentials are not valid.);
throw new 
 FtpTransferException(ECCUtils.ERROR_FTP_LOGIN);
}
ftpClient.execPBSZ(0);
ftpClient.execPROT(P);
boolean success = ftpClient.storeFile(fileName, fis);
if (!success) {
// this is false if NoSessionReuseRequired is not set
}
 Now my question is if it is generally possible to connect to a server
 with TLSProtocol TLSv1 or TLSProtocol SSLv23 without the
 NoSessionReuseRequired parameter? Could someone provide a piece of
 example code for this?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (NET-408) problem connecting to ProFTPD with FTPES

2011-05-18 Thread Bogdan Drozdowski (JIRA)


[ 
https://issues.apache.org/jira/browse/NET-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13035478#comment-13035478
 ] 

Bogdan Drozdowski commented on NET-408:
---

Try adding the TLSv1 protocol to the FTPSClient (if it's not there yet) with 
the getEnabledProtocols() and setEnabledProtocols() methods. Also, the server 
displays certificate unknown. Perhaps a client certificate was required by 
the server and none was provided to the FTPSCilent class.

About session reusing: it doesn't look like it's implemented in FTPSClient (all 
connections are created fresh), so right now you have to disable requiring 
session reuse in your server.

Try implicit SSL mode and see if you get the same error when connecting.

I won't be much of a help, because my ProFTPd is not SSL-enabled and rejects 
AUTH TLS.

 problem connecting to ProFTPD with FTPES
 

 Key: NET-408
 URL: https://issues.apache.org/jira/browse/NET-408
 Project: Commons Net
  Issue Type: Bug
  Components: FTP
Affects Versions: 2.2, 3.0
 Environment: ProFTPD 1.3.3d on SUSE Linux Enterprise Server 10.1 
 32bit, Kernel 2.6.16.46-0.12-default (config file attached)
 ProFTPD 1.3.3d on OpenSUSE 64bit Linux 2.6.34.8-0.2-desktop
 Java 1.5
Reporter: Michael Voigt
 Attachments: ftpes.jpg, proftpd.conf


 I have a problem with the FTPClient connecting to a ProFTPD server.
 If the server uses the configuration option TLSProtocol TLSv1, I
 cannot connect to it at all. I recieve the following error message:
 - javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection
 On the server side I see in the log:
 unable to accept TLS connection: protocol error:
 -  (1) error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert
 certificate unknown
 - TLS/TLS-C negotiation failed on control channel
 If the server uses the configuration option TLSProtocol SSLv23, I
 can connect to it but I cant transfer any files. In the server log I
 see:
 - starting TLS negotiation on data connection
 - TLSv1/SSLv3 renegotiation accepted, using cipher RC4-MD5 (128 bits)
 - client did not reuse SSL session, rejecting data connection (see
 TLSOption NoSessionReuseRequired)
 - unable to open data connection: TLS negotiation failed
 If I add the NoSessionReuseRequired parameter to the ProFTPD config
 everything works fine.
 Here is my code:
FTPClient ftpClient = new FTPClient();
ftpClient = new FTPSClient(TLS);
// this throws an exception with TLSProtocol TLSv1
ftpClient.connect(host, port);
int reply = ftpClient.getReplyCode();
if (!FTPReply.isPositiveCompletion(reply)) {
ftpClient.disconnect();
log.error(The FTP Server did not return a positive 
 completion reply!);
throw new 
 FtpTransferException(ECCUtils.ERROR_FTP_CONNECTION);
}
boolean loginSuccessful = ftpClient.login(userName, password);
if (!loginSuccessful) {
log.error(Login to the FTP Server failed! The 
 credentials are not valid.);
throw new 
 FtpTransferException(ECCUtils.ERROR_FTP_LOGIN);
}
ftpClient.execPBSZ(0);
ftpClient.execPROT(P);
boolean success = ftpClient.storeFile(fileName, fis);
if (!success) {
// this is false if NoSessionReuseRequired is not set
}
 Now my question is if it is generally possible to connect to a server
 with TLSProtocol TLSv1 or TLSProtocol SSLv23 without the
 NoSessionReuseRequired parameter? Could someone provide a piece of
 example code for this?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (NET-402) BufferedReader used for control channel, which does not follow the standard

2011-04-12 Thread Bogdan Drozdowski (JIRA)


[ 
https://issues.apache.org/jira/browse/NET-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13018907#comment-13018907
 ] 

Bogdan Drozdowski commented on NET-402:
---

Daniel, look at bug NET-349, which, by the way, should be closed along with 
this issue. Although many operating systems will prevent the user from creating 
files with CRs or LFs in the name, this is not forbidden by many filesystems 
(often the only forbidden character is the binary zero byte). So even if the 
server is conforming, a file-listing command result can break parsing just 
because the filename had a CR/LF. Similar things could happen anywhere where 
the client receives a listing of filesystem names (probably including IMAP, 
where you can create your own mailboxes).

So, on one hand, we stop supporting non-conforming servers (which could mean 
that we're supporting less servers now), but on the other hand we're fixing a 
bug that someone has found in a real-life system.

 BufferedReader used for control channel, which does not follow the standard
 ---

 Key: NET-402
 URL: https://issues.apache.org/jira/browse/NET-402
 Project: Commons Net
  Issue Type: Bug
Affects Versions: 2.2
Reporter: Sebb
 Fix For: 3.0


 BufferedReader is used for wrapping the control channel, and uses its 
 readLine() for getting responses from the server.
 The IMAP, NNTP, POP3 and SMTP protocols require CRLF at the end of lines, but 
 Bufferedreader#readLine() also allows bare CR and LF terminators, which could 
 potentially be included in a server reply.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (NET-397) FTPSClient does not handle AUTH or ADAT and only partially handles PBSZ. FTPSCommand should be deprecated

2011-04-01 Thread Bogdan Drozdowski (JIRA)

[
https://issues.apache.org/jira/browse/NET-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13014783#comment-13014783
]

Bogdan Drozdowski commented on NET-397:
---

Deprecating FTPSCommand is probably a good idea, because commands shouldn't be
spread among many files. But before the file gets removed, how about increasing
the integer constants somewhere over the number of commands in FTPCOmmand? Like
AUTH=100, ADAT=101 and so on. This would no more make conflicts. Then change
the command array in FTPSCommand to have the right number of null entries
before the right commands (static initializer block). And if the index given to
getCommand() is too low, FTPSCommand could even delegate the call to FTPCommand.

You're right about sendCommand() not being able to distinguish what to use, but
the new indices in FTPSCommand would fix this. Yes, if had been an enum from
the beginning, there wouldn't be problems like this, because the sendCommand()
methods would have different signatures. But still either the commands would be
spread among 2 files or all would be in FTPCommand and the plain FTPClient
would now have to accept FTP-only commands and FTPSClient - FTPS commands (and
delegate the rest to FTPClient).

Now that we have execXXX() methods, FTPSCommand is unused.

Just parsing the PBSZ reply is still a good idea - the user can call
setSendBufferSize()/setReceiveBufferSize() if this is the right thing to do.

Although isProtectedReplyCode() is FTPS-specific, it's a good idea that it's
now in FTPReply - everything in one place.

I keep command names public, so the users can send them manually, if they want
(like when they think Base64 or something else is buggy), but otherwise there
are no other reasons to do this.

No other issues right now. If I find something about PBSZ that would be worth
implementing separately, I'll let you know.

FTPSClient does not handle AUTH or ADAT and only partially handles PBSZ.
FTPSCommand should be deprecated
--

Key: NET-397
URL: https://issues.apache.org/jira/browse/NET-397
Project: Commons Net
Issue Type: Bug
Reporter: Sebb
Fix For: 3.0

Attachments: ftps-rfc2228.diff

FTPSClient does not provide any code to handle AUTH or ADAT, and does not
provide support for handling a reduced buffer size provided by the server.
FTPSCommand defines int values for AUTH and ADAT, but if the integer values
are used by client code, the value will be passed to FTPClient, which uses
its own array of command strings, and FTPSCommand.AUTH will translate to
USER and ADAT = PASS, similarly for PBSZ, PROT and CCC.
These commands all need special handling, so should be dealt with by
FTPSClient only.
FTPSClient can override the sendCommand(int) and sendCommand(int, String)
methods in FTPClient which will help prevent problems.
Since most of these commands need additional special handling, there should
be execNAME() methods for each.
FTPSCommand should be deprecated.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (NET-382) Subclasses of SocketClient should use _input_ and _output_ rather than calling _socket_.getInputStream() etc

2011-03-31 Thread Bogdan Drozdowski (JIRA)

[
https://issues.apache.org/jira/browse/NET-382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Bogdan Drozdowski updated NET-382:
--

Attachment: sockclient-socket-private.diff

I thought about that this too one day. Now I have a patch. It allows the user
to get the current socket, set a new one (automatically updating _input and
_output) and get the current streams. If accepted, _socket, _input and _output
can be made private and the subclasses modified to fit the new interface. This
will force the subclasses to use _input and _output. It still is one call, but
this time the call simply returns a field.

I don't like getSocket(), but it's required by classes that can, for example,
switch between encrypted and plain-text modes (like FTPSClient) to save to
original socket. Better than relying on a field name, anyway. The classes that
inherit from SocketClient still can modify the Socket the way they like, so
it's no worse than what it's like currently.

BufferedReaders/Writers are subclass-specific, so they can't be set
automatically when changing the socket. But it's probably useless to have them
in a general-purpose socket class, since they could be unused. So it's probably
best to leave things as they are: let the subclasses worry about these.

Subclasses of SocketClient should use _input_ and _output_ rather than
calling _socket_.getInputStream() etc

Key: NET-382
URL: https://issues.apache.org/jira/browse/NET-382
Project: Commons Net
Issue Type: Bug
Reporter: Sebb
Attachments: sockclient-socket-private.diff

SocketClient._connectAction() sets up \_input\_ and \_output\_ from
\_socket\_ so it is wasteful to do this again in subclasses.
Potentially consider making \_socket\_ private?
However, this would currently break most of the S versions of the
protocols, unless SocketClient is extended to handle their needs.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (NET-382) Subclasses of SocketClient should use _input_ and _output_ rather than calling _socket_.getInputStream() etc

2011-03-31 Thread Bogdan Drozdowski (JIRA)


 [ 
https://issues.apache.org/jira/browse/NET-382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bogdan Drozdowski updated NET-382:
--

Attachment: (was: sockclient-socket-private.diff)

 Subclasses of SocketClient should use _input_ and _output_ rather than 
 calling _socket_.getInputStream() etc
 

 Key: NET-382
 URL: https://issues.apache.org/jira/browse/NET-382
 Project: Commons Net
  Issue Type: Bug
Reporter: Sebb

 SocketClient._connectAction() sets up \_input\_ and \_output\_ from 
 \_socket\_ so it is wasteful to do this again in subclasses.
 Potentially consider making \_socket\_ private?
 However, this would currently break most of the S versions of the 
 protocols, unless SocketClient is extended to handle their needs.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (NET-382) Subclasses of SocketClient should use _input_ and _output_ rather than calling _socket_.getInputStream() etc

2011-03-31 Thread Bogdan Drozdowski (JIRA)


 [ 
https://issues.apache.org/jira/browse/NET-382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bogdan Drozdowski updated NET-382:
--

Attachment: sockclient-socket-private.diff

Sorry, the attachment had an error. Now fixed and attached again.

 Subclasses of SocketClient should use _input_ and _output_ rather than 
 calling _socket_.getInputStream() etc
 

 Key: NET-382
 URL: https://issues.apache.org/jira/browse/NET-382
 Project: Commons Net
  Issue Type: Bug
Reporter: Sebb
 Attachments: sockclient-socket-private.diff


 SocketClient._connectAction() sets up \_input\_ and \_output\_ from 
 \_socket\_ so it is wasteful to do this again in subclasses.
 Potentially consider making \_socket\_ private?
 However, this would currently break most of the S versions of the 
 protocols, unless SocketClient is extended to handle their needs.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (NET-397) FTPSClient does not handle AUTH or ADAT and only partially handles PBSZ. FTPSCommand should be deprecated

2011-03-31 Thread Bogdan Drozdowski (JIRA)

[
https://issues.apache.org/jira/browse/NET-397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Bogdan Drozdowski updated NET-397:
--

Attachment: ftps-rfc2228.diff

This patch adds the support for 5 missing commands from RFC2228: AUTH, ADAT,
MIC, ENC and CONF. PROT, CCC and PBSZ were already supported. The patch also
adds a convenience method for CCC, so that the overridden sendCommand (which
looks for CCC) can probably be removed.

The user still has to provide the data and potentially browse the replies if
necessary, but base64-encoding is done automatically. There also is a method
for getting ADAT data from the response.

FTPSCommand could be removed or a new method, say sendFTPSCommand(), added to
FTPSClient. This patch does not provide sendFTPSCommand() or other overridden
versions of sendCommand() in case FTPSCommand is removed.

Don't know how to fix PBSZ. Setting the buffer size in the Socket is probably
not enough?

FTPSClient does not handle AUTH or ADAT and only partially handles PBSZ.
FTPSCommand should be deprecated
--

Key: NET-397
URL: https://issues.apache.org/jira/browse/NET-397
Project: Commons Net
Issue Type: Bug
Reporter: Sebb
Attachments: ftps-rfc2228.diff

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (NET-333) would you provide a class used for imap protocol?

2011-03-29 Thread Bogdan Drozdowski (JIRA)


[ 
https://issues.apache.org/jira/browse/NET-333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13012393#comment-13012393
 ] 

Bogdan Drozdowski commented on NET-333:
---

Right, overriding generateCommandID() is enough.

About the generateCommandID() test: I meant something like when the generator 
sees '', it extends the tag to 'A' (5 chars now, while the initial has 
4), not wraps to ''. This way initial.equals(s) would never be true, but we 
don't have to worry about that now (when we have a fixed-size generator with a 
period of 26^4), because probably there won't be any need for more tags.

Now about Enum.name(): yes, I checked the javadoc before. I can't reproduce 
that problem now (seems to be working well all the time), so let's assume it's 
working correctly.

No more questions/issues on my side right now.

 would you provide a class used for imap protocol?
 -

 Key: NET-333
 URL: https://issues.apache.org/jira/browse/NET-333
 Project: Commons Net
  Issue Type: Improvement
Reporter: iceviewer
 Attachments: IMAP.zip, IMAPMail.java


 would you provide a class used for imap protocol?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (NET-333) would you provide a class used for imap protocol?

2011-03-28 Thread Bogdan Drozdowski (JIRA)


[ 
https://issues.apache.org/jira/browse/NET-333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13012020#comment-13012020
 ] 

Bogdan Drozdowski commented on NET-333:
---

What fields in IMAPReply are needed? The reply codes? Now, since reply parsing 
is in the same class, they're just in case the user wants to check manually.

Yes, users can override the generateCommandID() method, but not only this 
requires a new class (can't do this from a class that's just using IMAP), but 
also the users can't override the initial tag this way.

Had a look at the code, looks good to me. I see you're testing the tag 
generator - good, because I've only checked only about 30 or 40 tags in a row 
(without sending any commands). On the other hand, if the generator increases 
the length instead of wrapping, a new test will have to be written (but it's 
not a problem right now). I've just spotted a tiny thing: in the example class, 
IMAPMail.java, you have:
{code}
// enable the next line if the server certificate has expired:
// ((IMAPSClient) 
imap).setTrustManager(TrustManagerUtils.getValidateServerCertificateTrustManager());
{code}
while I think it should be:
{code}
// enable the next line if the server certificate has NOT expired:
// ((IMAPSClient) 
imap).setTrustManager(TrustManagerUtils.getValidateServerCertificateTrustManager());
{code}
A tiny thing, but can confuse (if I'm right). And
{code}
public String getIMAPCommand() {
return imapCommand != null ? imapCommand : name();
}
{code}
should be changed to:
{code}
public String getIMAPCommand() {
return imapCommand != null ? imapCommand : toString();
}
{code}
because, as far as I remember, toString() actually returns the name of the 
constant, while name() returns something more - a more (or fully) qualified 
name of the constant. Probably not the thing we want. The enum can't be 
extended by user code, but looks cleaner than the original class.

 would you provide a class used for imap protocol?
 -

 Key: NET-333
 URL: https://issues.apache.org/jira/browse/NET-333
 Project: Commons Net
  Issue Type: Improvement
Reporter: iceviewer
 Attachments: IMAP.zip, IMAPMail.java


 would you provide a class used for imap protocol?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (NET-217) TFTPServerPathTest fails in testWriteOutsideHome

2011-03-27 Thread Bogdan Drozdowski (JIRA)


[ 
https://issues.apache.org/jira/browse/NET-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13011802#comment-13011802
 ] 

Bogdan Drozdowski commented on NET-217:
---

I had a similar problem with TCP Sockets - they remained in a non-closed state 
(like TIMED_WAIT, CLOSE_WAIT or whatever) despite having been closed and thus 
they couldn't be immediatly reopened. My solution was to set the Sockets to 
null (which you're doing already) and to manually force garbage collection by 
calling System.gc(), which you're not doing. Since TFTPServer is in test, and 
not in the main source package, I think that garbage collection could be added 
to shutdown() or after the call to shutdown() in TFTPServerPathTest. This might 
not be the problem, but I'm just saying what I've observed on my programs.

 TFTPServerPathTest fails in testWriteOutsideHome
 

 Key: NET-217
 URL: https://issues.apache.org/jira/browse/NET-217
 Project: Commons Net
  Issue Type: Bug
  Components: TFTP
Affects Versions: 2.0
 Environment: $ mvn -v
 Maven version: 2.0.8
 Java version: 1.6.0_06
 OS name: linux version: 2.6.24-16-generic arch: i386 Family: unix
Reporter: Niklas Gustavsson

 The TFTPServerPathTest fails in the testWriteOutsideHome method with the 
 following stack trace:
 Tests run: 3, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.045 sec  
 FAILURE!
 testWriteOutsideHome(org.apache.commons.net.tftp.TFTPServerPathTest)  Time 
 elapsed: 0.003 sec   ERROR!
 java.net.BindException: Address already in use
 at java.net.PlainDatagramSocketImpl.bind0(Native Method)
 at 
 java.net.PlainDatagramSocketImpl.bind(PlainDatagramSocketImpl.java:82)
 at java.net.DatagramSocket.bind(DatagramSocket.java:368)
 at java.net.DatagramSocket.init(DatagramSocket.java:210)
 at java.net.DatagramSocket.init(DatagramSocket.java:261)
 at java.net.DatagramSocket.init(DatagramSocket.java:234)
 at 
 org.apache.commons.net.DefaultDatagramSocketFactory.createDatagramSocket(DefaultDatagramSocketFactory.java:59)
 at 
 org.apache.commons.net.DatagramSocketClient.open(DatagramSocketClient.java:119)
 at org.apache.commons.net.tftp.TFTPServer.launch(TFTPServer.java:239)
 at org.apache.commons.net.tftp.TFTPServer.init(TFTPServer.java:161)
 at 
 org.apache.commons.net.tftp.TFTPServerPathTest.testWriteOutsideHome(TFTPServerPathTest.java:137)
 This breaks are build for FtpServer as we currently bring in commons-net as 
 there are no snapshots available.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (NET-320) Allow TFTPServer.java to bind to a specific network adapter

2011-03-27 Thread Bogdan Drozdowski (JIRA)

[
https://issues.apache.org/jira/browse/NET-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Bogdan Drozdowski updated NET-320:
--

Attachment: tftp-bind.diff

You probably only need to bind to a particular IP address, not to the whole
interface (there's no method of doing this, as far as I know).

This small patch adds two constructors: one taking an InetAddress to bind to
and the other taking a NetworkInterface. The first InetAddress of the given
interface will be the address the DatagramSocket will be bound to.

Allow TFTPServer.java to bind to a specific network adapter
---

Key: NET-320
URL: https://issues.apache.org/jira/browse/NET-320
Project: Commons Net
Issue Type: Improvement
Components: TFTP
Affects Versions: 2.0
Reporter: Kevin
Labels: NetworkInterface, TFTP, TFTPServer
Attachments: tftp-bind.diff

Original Estimate: 24h
Remaining Estimate: 24h

It would be very nice to specify exactly which network interface you would
like to bind the TFTP server listening port to. In some cases it's only
necessary to open up loopback, in other cases you may only want to bind to a
management network. I would like to see one of two things happen to satisfy
this requirement.

1) You could allow me to get a handle to the socket such that I can make
modifications to it on my own.
or
2) Add a constructor and/or method that allows me to pass a NetworkInterface
instance to specify which nic to bind the server to.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (NET-333) would you provide a class used for imap protocol?

2011-03-27 Thread Bogdan Drozdowski (JIRA)


[ 
https://issues.apache.org/jira/browse/NET-333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13011811#comment-13011811
 ] 

Bogdan Drozdowski commented on NET-333:
---

GMail doesn't seem to even support the port 143 (and you probably can't or 
normally don't issue a STARTTLS command on an SSL connection). Anyway, I'm glad 
it's working for you too now. Just a few more issues:
* if the IMAPReply class won't be final, change private to protected on at 
least the fields
* getAdditionalReply() still present, don't forget
* subtask 2 (sendCommandWithID): although we provide our own automatic tagging, 
the user may for some reason want or need custom tags (like the traditional 
A000 instead of our ).
* subtask 3 (sendUntaggedCommand): yes, see AuthenticatingIMAPClient.java. At 
least protected. But if the user wants to perform manual authentication (with 
some other method, like GSSAPI for example), these should be public.
* subtask 1 (enum issue): if you still want an enum after what I've said, I 
don't mind. You probably know better what you're doing :)

Nice work with the code, it's cleaner now.

 would you provide a class used for imap protocol?
 -

 Key: NET-333
 URL: https://issues.apache.org/jira/browse/NET-333
 Project: Commons Net
  Issue Type: Improvement
Reporter: iceviewer
 Attachments: IMAP.zip, IMAPMail.java


 would you provide a class used for imap protocol?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (NET-333) would you provide a class used for imap protocol?

2011-03-26 Thread Bogdan Drozdowski (JIRA)


[ 
https://issues.apache.org/jira/browse/NET-333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13011628#comment-13011628
 ] 

Bogdan Drozdowski commented on NET-333:
---

Explicit mode doesn't hang for me:
{noformat}
* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE STARTTLS 
AUTH=PLAIN AUTH=LOGIN AUTH=CRAM-MD5] Dovecot ready.

TLS: success='true', reply:  OK Begin TLS negotiation now.

LOGIN: success='true', reply: AAAB OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR 
LOGIN-REFERRALS ID ENABLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS 
MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 
CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS] 
Logged in

CAPA: success='true', reply: * CAPABILITY IMAP4rev1 LITERAL+ SASL-IR 
LOGIN-REFERRALS ID ENABLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS 
MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 
CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS 
  
AAAC OK Capability completed.

NOOP: success='true', reply: AAAD OK NOOP completed.

SELECT: success='true', reply: * FLAGS (\Answered \Flagged \Deleted \Seen 
\Draft) 
  
* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags 
permitted.
{noformat}
My code is:
{code}
IMAPSClient c = new IMAPSClient (false);
c.setTrustManager (new X509TrustManager ()
{
private final java.security.cert.X509Certificate[]
EMPTY_X509CERTIFICATE_ARRAY = new 
java.security.cert.X509Certificate[]{};

/**
* No-op
*/
public void checkClientTrusted(java.security.cert.X509Certificate[] 
certificates, String authType)
{
return;
}

public void checkServerTrusted(java.security.cert.X509Certificate[] 
certificates,
   String authType)
   throws 
java.security.cert.CertificateExpiredException,

java.security.cert.CertificateNotYetValidException
{
for (int i = 0; i  certificates.length; ++i)
{
certificates[i].checkValidity();
}
}

public java.security.cert.X509Certificate[] getAcceptedIssuers()
{
return EMPTY_X509CERTIFICATE_ARRAY;
}
});
c.setEnabledProtocols (new String[] {SSLv3, TLSv1, SSLv2Hello});
c.connect (127.0.0.1, 143);
System.out.println (c.getReplyString());
boolean a;
a = c.execTLS();
System.out.println (TLS: success=' + a + ', reply:  + c.getReplyString());
a = c.login (bogdan, bogdan);
System.out.println (LOGIN: success=' + a + ', reply:  + c.getReplyString());
a = c.capability();
System.out.println (CAPA: success=' + a + ', reply:  + c.getReplyString());
a = c.noop();
System.out.println (NOOP: success=' + a + ', reply:  + c.getReplyString());
a = c.select(inbox);
System.out.println (SELECT: success=' + a + ', reply:  + 
c.getReplyString());
{code}
You can seee an accept-all TrustManager, which I've used then because of the 
same Exception you had.

You're right about the * OK. I see two solutions: remember the last tag and 
scan for it in the response (your solution) or make a boolean saying that the 
initial response has already been received, so scanning for untagged OK 
responses should not happen anymore. The '*' stays as a line continuation mark, 
however.

Lookin closer at the file in the repository:
* the // The length() ... comment in __getReply() can be removed
* the getAdditionalReply() method *probably* won't be needed any more (I don't 
know how does an IMAP server return a message body, but I presume it'll be 
followed by a tagged response anyway). I copied it from POP3Client, but IMAP 
probably works in a different way
* IMAPMail has all responses commented-out. Just checking: was this the way it 
was supposed to be (just to show the usage, not the replies)? Anyway, 
imap.getAdditionalReply() may hang, because it waits for a line consisting of 
only a period, and this is probably not a part of the IMAP protocol.

Sorry for not replying for so long, I had no time for this recently.

 would you provide a class used for imap protocol?
 -

 Key: NET-333
 URL: https://issues.apache.org/jira/browse/NET-333
 Project: Commons Net
  Issue Type: Improvement
Reporter: iceviewer
 Attachments: IMAP.zip, IMAPMail.java


 would you provide a class used for imap protocol?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (NET-333) would you provide a class used for imap protocol?

2011-03-23 Thread Bogdan Drozdowski (JIRA)


 [ 
https://issues.apache.org/jira/browse/NET-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bogdan Drozdowski updated NET-333:
--

Attachment: (was: IMAPMail.java)

 would you provide a class used for imap protocol?
 -

 Key: NET-333
 URL: https://issues.apache.org/jira/browse/NET-333
 Project: Commons Net
  Issue Type: Improvement
Reporter: iceviewer
 Attachments: IMAP.zip


 would you provide a class used for imap protocol?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (NET-333) would you provide a class used for imap protocol?

2011-03-23 Thread Bogdan Drozdowski (JIRA)


 [ 
https://issues.apache.org/jira/browse/NET-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bogdan Drozdowski updated NET-333:
--

Attachment: IMAPMail.java

I only needed to add a TrustManager (now since we don't have a default). And it 
works for me:
{noformat}
[bogdan@orion Commons-Net]$ java -cp 
.:/home/bogdan/RPMS/java/commons-net-2.2/commons-net-2.2.jar IMAPMail 
imap.gmail.com bogdan bogdan TLS 
Using secure protocol: TLS
Connecting to server imap.gmail.com on 993  
Could not login to server. Check password.   
[bogdan@orion Commons-Net]$ java -cp 
.:/home/bogdan/RPMS/java/commons-net-2.2/commons-net-2.2.jar IMAPMail 127.0.0.1 
bogdan bogdan TLS 
Using secure protocol: TLS
Connecting to server 127.0.0.1 on 993
Server capabilities:  
* CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT 
SORT=DISPLAY THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE CHILDREN 
NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT 
SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS   
AAAB OK Capability completed. 
Selected inbox:
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)  
* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags 
permitted.
Examined inbox:
* 0 EXISTS  
* 0 RECENT   
* OK [UIDVALIDITY 1269775345] UIDs valid 
Inbox status:
* OK [UIDNEXT 17] Predicted next UID 
{noformat}

By the way, since the default TrustManagers have been removed, the POP3Mail 
example has stopped working on SSL/TLS connections and needs to be changed, too.

I didn't change the javadoc. It can be change while committing to svn, but I 
can change it if you want.

 would you provide a class used for imap protocol?
 -

 Key: NET-333
 URL: https://issues.apache.org/jira/browse/NET-333
 Project: Commons Net
  Issue Type: Improvement
Reporter: iceviewer
 Attachments: IMAP.zip, IMAPMail.java


 would you provide a class used for imap protocol?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (NET-333) would you provide a class used for imap protocol?

2011-03-22 Thread Bogdan Drozdowski (JIRA)


[ 
https://issues.apache.org/jira/browse/NET-333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009636#comment-13009636
 ] 

Bogdan Drozdowski commented on NET-333:
---

Why not an enum? The reason I had was simple: although enums provide type 
safety (which is very good), I believe enums can't be subclassed nor they can 
derive from other classes, so if we have enum IMAPCommand, we can't have a 
class, say public class IMAPSCommand extends IMAPCommand or public enum 
IMAPSCommand extends IMAPCommand. This means that additional commands must 
either be inserted into the base class, say IMAPCommand (now what if you're 
using just the binary release?), or inserted into the class that uses them 
(like I did in the AuthenticatingSMTPClient or ExtendedPOP3Client), or have 
their own class, completely unrelated to the base class. The first is possible 
only if you have the source and either build it yourself or wait for your patch 
to be applied, because it's impossible to subclass the base class currently. 
The second and third solutions, on the other hand, spread the set of commands 
among many classes. That's why I did it this way. With this in mind, the 
final keyword on the IMAPReply class declaration is an error, I copied too 
much from other classes. If these classes aren't made enum/final, users can 
subclass them without the source code and inherit all the commands/replies 
automatically, so they can, for example, subclass *Client classes and have them 
use or produce their own subclasses of *Command and *Reply.

I'm not currently subscribed to the mailing list, I'll browse the archives to 
check the volume and perhaps I'll join you. Yes, some code is plainly copied 
between the classes, but the details vary. Every clas has a __getReply() but, 
for example, the line continuation algorithm varies. This could be made 
abstract, but what if we want just a SocketClient? We couldn't instantiate it 
now. Currently (in the classes I'm interested in: IMAP, POP3, SMTP, FTP) I can 
see that add/removeProtocolCommandListener could be immediately pushed up 
either to SocketClient or to something new between the SocketClient class and 
the protocol classes (not the *Client classes).

Did you verify that POP3SClient and SMTPSClient work for you? I used them and 
they worked fine for me, but the IMAPSClient shows that they shouldn't (because 
they don't replace _reader and _writer from the SSLSocket) and I'm puzzled.

 would you provide a class used for imap protocol?
 -

 Key: NET-333
 URL: https://issues.apache.org/jira/browse/NET-333
 Project: Commons Net
  Issue Type: Improvement
Reporter: iceviewer
 Attachments: IMAP.zip


 would you provide a class used for imap protocol?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (NET-333) would you provide a class used for imap protocol?

2011-03-22 Thread Bogdan Drozdowski (JIRA)


 [ 
https://issues.apache.org/jira/browse/NET-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bogdan Drozdowski updated NET-333:
--

Attachment: IMAPMail.java

Here is a simple class that demonstrates the use of the IMAP protocol classes 
provided in the ZIP package. Is simply logs the user in and performs a few 
commands on the inbox folder. Like in the IMAP classes, there is no reply 
parsing, the program simply displays what the server has sent. I don't know the 
IMAP protocol very well, hence this is as it is right now. The IMAP classes 
should be extended one day (either by me, but later, or by someone who knows 
the protocol better) to provide server reply parsing, so the user gets more 
friendly erplis (like the number of messages or something like that). The 
example class has been tested with dovecot, the IMAP classes have been tested 
with dovecot and cyrus-imapd.

 would you provide a class used for imap protocol?
 -

 Key: NET-333
 URL: https://issues.apache.org/jira/browse/NET-333
 Project: Commons Net
  Issue Type: Improvement
Reporter: iceviewer
 Attachments: IMAP.zip, IMAPMail.java


 would you provide a class used for imap protocol?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (NET-326) A KeyManager is required when the protection level is set to 'P' with FTPSClient on active mode

2011-03-22 Thread Bogdan Drozdowski (JIRA)


[ 
https://issues.apache.org/jira/browse/NET-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009641#comment-13009641
 ] 

Bogdan Drozdowski commented on NET-326:
---

You're right, the alias could be useful, but it may not always be necessary. I 
like the current solution of
{code}
keyAlias != null ? keyAlias : findAlias(ks)
{code}
It has both our ideas.

 A KeyManager is required when the protection level is set to 'P' with 
 FTPSClient on active mode
 ---

 Key: NET-326
 URL: https://issues.apache.org/jira/browse/NET-326
 Project: Commons Net
  Issue Type: Bug
  Components: FTP
Affects Versions: 2.0
 Environment: Windows XP profesional service pack 2, Java Java 
 1.6.0_12-b04 
Reporter: Terence Dudouit
 Attachments: SSLContextsFactory.java


 Using a simple FTPS client that list a directory, when execPROT(P) is set 
 and the active mode is on, the following exception is thrown :
 javax.net.ssl.SSLException: No available certificate or key corresponds to 
 the SSL cipher suites which are enabled.
   at 
 com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.checkEnabledSuites(SSLServerSocketImpl.java:303)
   at 
 com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.accept(SSLServerSocketImpl.java:253)
   at 
 org.apache.commons.net.ftp.FTPClient._openDataConnection_(FTPClient.java:489)
   at 
 org.apache.commons.net.ftp.FTPSClient._openDataConnection_(FTPSClient.java:494)
   at org.apache.commons.net.ftp.FTPClient.listNames(FTPClient.java:1950)
   at org.apache.commons.net.ftp.FTPClient.listNames(FTPClient.java:1996)
   at 
 fr.enovacom.eai.actions.dynamiques.protocole.ftp.FTPGet.testFTPS(FTPGet.java:379)
   at 
 fr.enovacom.eai.actions.dynamiques.protocole.ftp.FTPGet.main(FTPGet.java:401)
 This doesn't occur on passive mode.
 The only way to make it work is to set a keyManager although there is no need 
 for a client authentication.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (NET-333) would you provide a class used for imap protocol?

2011-03-22 Thread Bogdan Drozdowski (JIRA)


[ 
https://issues.apache.org/jira/browse/NET-333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009748#comment-13009748
 ] 

Bogdan Drozdowski commented on NET-333:
---

I'm glad SMTPS and POP3S work for you, but I'm worndering how is that possible. 
Commands sending is done via a Writer connected to the old socket and that's 
why I get a Connection reset in IMAP. Strange, I'll take a look later.

Tell me google's IMAP server's address and port and I'll try. nc gmail.com 
143 doesn't work for me now.

Since you already have an IMAP implementation, why wasn't this bug closed for 
such a long time? Or the Commons-Net code merged with the existing code and the 
bug closed afterwards? Anyway, the code currently is rather low-level, as you 
can see, and I won't make it high-level quickly. But it still can be useful. If 
you want only simple code, you have it :).

 would you provide a class used for imap protocol?
 -

 Key: NET-333
 URL: https://issues.apache.org/jira/browse/NET-333
 Project: Commons Net
  Issue Type: Improvement
Reporter: iceviewer
 Attachments: IMAP.zip, IMAPMail.java


 would you provide a class used for imap protocol?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (NET-326) A KeyManager is required when the protection level is set to 'P' with FTPSClient on active mode

2011-03-21 Thread Bogdan Drozdowski (JIRA)


[ 
https://issues.apache.org/jira/browse/NET-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009119#comment-13009119
 ] 

Bogdan Drozdowski commented on NET-326:
---

Good job. A simple class with a simple API. Different from mine, because it 
requires an alias of the certificate to be provided (mine didn't require), but 
simpler, which is good.

One more thing I've noticed recently: the S clients' (SMTPS, POP3S, FTPS) 
constructors have an unnecessary line in their javadoc, a leftover after 
removing the exception description. Could you fix that?

 A KeyManager is required when the protection level is set to 'P' with 
 FTPSClient on active mode
 ---

 Key: NET-326
 URL: https://issues.apache.org/jira/browse/NET-326
 Project: Commons Net
  Issue Type: Bug
  Components: FTP
Affects Versions: 2.0
 Environment: Windows XP profesional service pack 2, Java Java 
 1.6.0_12-b04 
Reporter: Terence Dudouit
 Attachments: SSLContextsFactory.java


 Using a simple FTPS client that list a directory, when execPROT(P) is set 
 and the active mode is on, the following exception is thrown :
 javax.net.ssl.SSLException: No available certificate or key corresponds to 
 the SSL cipher suites which are enabled.
   at 
 com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.checkEnabledSuites(SSLServerSocketImpl.java:303)
   at 
 com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.accept(SSLServerSocketImpl.java:253)
   at 
 org.apache.commons.net.ftp.FTPClient._openDataConnection_(FTPClient.java:489)
   at 
 org.apache.commons.net.ftp.FTPSClient._openDataConnection_(FTPSClient.java:494)
   at org.apache.commons.net.ftp.FTPClient.listNames(FTPClient.java:1950)
   at org.apache.commons.net.ftp.FTPClient.listNames(FTPClient.java:1996)
   at 
 fr.enovacom.eai.actions.dynamiques.protocole.ftp.FTPGet.testFTPS(FTPGet.java:379)
   at 
 fr.enovacom.eai.actions.dynamiques.protocole.ftp.FTPGet.main(FTPGet.java:401)
 This doesn't occur on passive mode.
 The only way to make it work is to set a keyManager although there is no need 
 for a client authentication.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (NET-333) would you provide a class used for imap protocol?

2011-03-21 Thread Bogdan Drozdowski (JIRA)


 [ 
https://issues.apache.org/jira/browse/NET-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bogdan Drozdowski updated NET-333:
--

Attachment: IMAP.zip

Basic functionalicty included: connecting, authentication, SSL/TLS. All 
commands supported, no reply parsing (except for the return code - OK, ERROR, 
...), some enums for easier use.

The Authenticating client constructors delegate to IMAPS constructors, this may 
be unneeded.

When entering secure mode, not only the socket and the corresponding 
input/output streams are replaced, but also the bufferred reader+writer. This 
wasn't done in SMTPSClient and POP3SClient (and they seemd to work), but was 
done in FTPSClient and IMAPSClient doesn't seem to work without this. Which way 
is correct (I'd guess that FTP)?

 would you provide a class used for imap protocol?
 -

 Key: NET-333
 URL: https://issues.apache.org/jira/browse/NET-333
 Project: Commons Net
  Issue Type: Improvement
Reporter: iceviewer
 Attachments: IMAP.zip


 would you provide a class used for imap protocol?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (NET-326) A KeyManager is required when the protection level is set to 'P' with FTPSClient on active mode

2011-03-21 Thread Bogdan Drozdowski (JIRA)


[ 
https://issues.apache.org/jira/browse/NET-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009160#comment-13009160
 ] 

Bogdan Drozdowski commented on NET-326:
---

Yes, that's precisely what I meant. Thank you!

About the multiple keys: I assumed that only a keystore is required and the 
certificate is chosen basing on things like the Common Name field. I could be 
wrong, of course.

 A KeyManager is required when the protection level is set to 'P' with 
 FTPSClient on active mode
 ---

 Key: NET-326
 URL: https://issues.apache.org/jira/browse/NET-326
 Project: Commons Net
  Issue Type: Bug
  Components: FTP
Affects Versions: 2.0
 Environment: Windows XP profesional service pack 2, Java Java 
 1.6.0_12-b04 
Reporter: Terence Dudouit
 Attachments: SSLContextsFactory.java


 Using a simple FTPS client that list a directory, when execPROT(P) is set 
 and the active mode is on, the following exception is thrown :
 javax.net.ssl.SSLException: No available certificate or key corresponds to 
 the SSL cipher suites which are enabled.
   at 
 com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.checkEnabledSuites(SSLServerSocketImpl.java:303)
   at 
 com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.accept(SSLServerSocketImpl.java:253)
   at 
 org.apache.commons.net.ftp.FTPClient._openDataConnection_(FTPClient.java:489)
   at 
 org.apache.commons.net.ftp.FTPSClient._openDataConnection_(FTPSClient.java:494)
   at org.apache.commons.net.ftp.FTPClient.listNames(FTPClient.java:1950)
   at org.apache.commons.net.ftp.FTPClient.listNames(FTPClient.java:1996)
   at 
 fr.enovacom.eai.actions.dynamiques.protocole.ftp.FTPGet.testFTPS(FTPGet.java:379)
   at 
 fr.enovacom.eai.actions.dynamiques.protocole.ftp.FTPGet.main(FTPGet.java:401)
 This doesn't occur on passive mode.
 The only way to make it work is to set a keyManager although there is no need 
 for a client authentication.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (NET-370) Add support for FTP commands MLSD, MLST

2011-03-18 Thread Bogdan Drozdowski (JIRA)


[ 
https://issues.apache.org/jira/browse/NET-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13008465#comment-13008465
 ] 

Bogdan Drozdowski commented on NET-370:
---

This is a duplicate of NET-378. MLST and MLSD have recently been implemented.

 Add support for FTP commands MLSD, MLST
 ---

 Key: NET-370
 URL: https://issues.apache.org/jira/browse/NET-370
 Project: Commons Net
  Issue Type: New Feature
Affects Versions: 2.2
Reporter: Sebb

 MLSD and MSLT are intended for machine parsing of listings, so if the server 
 supports the features it would be beneficial to use them.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (NET-273) FEAT response parsing

2011-03-18 Thread Bogdan Drozdowski (JIRA)


[ 
https://issues.apache.org/jira/browse/NET-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13008468#comment-13008468
 ] 

Bogdan Drozdowski commented on NET-273:
---

Since new features can be added at any moment, I'd see the tests as 
client.supportsFeature(something), with a list of currently-known features in 
a separate class (FTPFeature.java), so client.supportsFeature(FTPFeature.FOO) 
could also be used. Not all commands are features and not all feature names are 
commands, so a separate class would be better.

I'd use a java.util.MapString, String to hold the features. The number of 
entries (keys) in the Map would be the number of features the server reported. 
The first String in an entry would be the first word on a line from the feature 
list (which should be the feature's name), the second String would be the 
feature's options - everything after the feature's name (like for MLST).

 FEAT response parsing
 -

 Key: NET-273
 URL: https://issues.apache.org/jira/browse/NET-273
 Project: Commons Net
  Issue Type: Improvement
  Components: FTP
Affects Versions: 2.0
Reporter: Shikhar Bhushan
Priority: Minor

 Would be nice if response to FEAT could be parsed, and a simple method 
 provided like client.isSupported(FTPCommand.MDTM)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (NET-326) A KeyManager is required when the protection level is set to 'P' with FTPSClient on active mode

2011-03-16 Thread Bogdan Drozdowski (JIRA)


[ 
https://issues.apache.org/jira/browse/NET-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13007541#comment-13007541
 ] 

Bogdan Drozdowski commented on NET-326:
---

Quick fixing :)

Now that I see that the code has grown a bit, wrapping the other calls makes 
little sense. But now creating more methods, similar to the above (with an 
explicit algorithm or provider), with an extra parameter of a KeyStore makes 
more sense.

Now the question is: will we always have an instance of X509TrustManager? 
Keytool allows creating other keys, not only RSA. But I'm not sure. Anyway, 
perhaps the best solution is leave it as it is and have the user catch a 
ClassCastException if something went wrong. The only thing we could do is 
search the array for the first instance of X509TrustManager, which could in 
turn, return the non-first element (could it still be called the default?), 
which could cause even more mess. I'm just thinking out loud, probably these 
problems will never happen, because the user should have prepared a proper 
keystore in the first place.

I've just remembered: if you accept my file, add a @see tag to the 
contructors that use SSLContexts and, independly of that, add a @see tag to 
the TrustManager-setters in FTPSClient, SMTPSClient and POP3SClient, so the 
users can find the new class.

 A KeyManager is required when the protection level is set to 'P' with 
 FTPSClient on active mode
 ---

 Key: NET-326
 URL: https://issues.apache.org/jira/browse/NET-326
 Project: Commons Net
  Issue Type: Bug
  Components: FTP
Affects Versions: 2.0
 Environment: Windows XP profesional service pack 2, Java Java 
 1.6.0_12-b04 
Reporter: Terence Dudouit
 Attachments: SSLContextsFactory.java


 Using a simple FTPS client that list a directory, when execPROT(P) is set 
 and the active mode is on, the following exception is thrown :
 javax.net.ssl.SSLException: No available certificate or key corresponds to 
 the SSL cipher suites which are enabled.
   at 
 com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.checkEnabledSuites(SSLServerSocketImpl.java:303)
   at 
 com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.accept(SSLServerSocketImpl.java:253)
   at 
 org.apache.commons.net.ftp.FTPClient._openDataConnection_(FTPClient.java:489)
   at 
 org.apache.commons.net.ftp.FTPSClient._openDataConnection_(FTPSClient.java:494)
   at org.apache.commons.net.ftp.FTPClient.listNames(FTPClient.java:1950)
   at org.apache.commons.net.ftp.FTPClient.listNames(FTPClient.java:1996)
   at 
 fr.enovacom.eai.actions.dynamiques.protocole.ftp.FTPGet.testFTPS(FTPGet.java:379)
   at 
 fr.enovacom.eai.actions.dynamiques.protocole.ftp.FTPGet.main(FTPGet.java:401)
 This doesn't occur on passive mode.
 The only way to make it work is to set a keyManager although there is no need 
 for a client authentication.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (NET-326) A KeyManager is required when the protection level is set to 'P' with FTPSClient on active mode

2011-03-14 Thread Bogdan Drozdowski (JIRA)


[ 
https://issues.apache.org/jira/browse/NET-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13006504#comment-13006504
 ] 

Bogdan Drozdowski commented on NET-326:
---

Nice one. But now I have a question: why do you cast a TrustManagerFactory 
(which implements od extends nothing) to a X509TrustManager? Are you sure that 
this will work?

I'd add just three more methods to your factory (assuming the casts are OK):
{code}
public static X509TrustManager getTrustManager(String algorithm) throws 
NoSuchAlgorithmException {
return (X509TrustManager) TrustManagerFactory.getInstance(algorithm);
}
public static X509TrustManager getTrustManager(String algorithm, Provider 
provider) throws NoSuchAlgorithmException {
return (X509TrustManager) TrustManagerFactory.getInstance(algorithm, 
provider);
}

public static X509TrustManager getTrustManager(String algorithm, String 
provider) throws NoSuchAlgorithmException {
return (X509TrustManager) TrustManagerFactory.getInstance(algorithm, 
provider);
}
{code}

so that the user could choose the algorithm the TrustManager will be used for. 
This is basically delegating the calls to the TrustManagerFactory, but we have 
everything in one place.

 A KeyManager is required when the protection level is set to 'P' with 
 FTPSClient on active mode
 ---

 Key: NET-326
 URL: https://issues.apache.org/jira/browse/NET-326
 Project: Commons Net
  Issue Type: Bug
  Components: FTP
Affects Versions: 2.0
 Environment: Windows XP profesional service pack 2, Java Java 
 1.6.0_12-b04 
Reporter: Terence Dudouit
 Attachments: SSLContextsFactory.java


 Using a simple FTPS client that list a directory, when execPROT(P) is set 
 and the active mode is on, the following exception is thrown :
 javax.net.ssl.SSLException: No available certificate or key corresponds to 
 the SSL cipher suites which are enabled.
   at 
 com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.checkEnabledSuites(SSLServerSocketImpl.java:303)
   at 
 com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.accept(SSLServerSocketImpl.java:253)
   at 
 org.apache.commons.net.ftp.FTPClient._openDataConnection_(FTPClient.java:489)
   at 
 org.apache.commons.net.ftp.FTPSClient._openDataConnection_(FTPSClient.java:494)
   at org.apache.commons.net.ftp.FTPClient.listNames(FTPClient.java:1950)
   at org.apache.commons.net.ftp.FTPClient.listNames(FTPClient.java:1996)
   at 
 fr.enovacom.eai.actions.dynamiques.protocole.ftp.FTPGet.testFTPS(FTPGet.java:379)
   at 
 fr.enovacom.eai.actions.dynamiques.protocole.ftp.FTPGet.main(FTPGet.java:401)
 This doesn't occur on passive mode.
 The only way to make it work is to set a keyManager although there is no need 
 for a client authentication.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (NET-326) A KeyManager is required when the protection level is set to 'P' with FTPSClient on active mode

2011-03-13 Thread Bogdan Drozdowski (JIRA)


 [ 
https://issues.apache.org/jira/browse/NET-326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bogdan Drozdowski updated NET-326:
--

Attachment: SSLContextsFactory.java

Here is a simple class that wraps all the SSLContext creation details in simple 
methods. There are 2 maximum methods (all parameters included), 1 minimum 
(just the keystore and a password to it) and some in between. Tested the 
simplest method - still works. Put it in the right package 
(org/apache/commons/net/util?), you can move tha anonymous class to a named 
inner class, if you like.

 A KeyManager is required when the protection level is set to 'P' with 
 FTPSClient on active mode
 ---

 Key: NET-326
 URL: https://issues.apache.org/jira/browse/NET-326
 Project: Commons Net
  Issue Type: Bug
  Components: FTP
Affects Versions: 2.0
 Environment: Windows XP profesional service pack 2, Java Java 
 1.6.0_12-b04 
Reporter: Terence Dudouit
 Attachments: SSLContextsFactory.java


 Using a simple FTPS client that list a directory, when execPROT(P) is set 
 and the active mode is on, the following exception is thrown :
 javax.net.ssl.SSLException: No available certificate or key corresponds to 
 the SSL cipher suites which are enabled.
   at 
 com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.checkEnabledSuites(SSLServerSocketImpl.java:303)
   at 
 com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.accept(SSLServerSocketImpl.java:253)
   at 
 org.apache.commons.net.ftp.FTPClient._openDataConnection_(FTPClient.java:489)
   at 
 org.apache.commons.net.ftp.FTPSClient._openDataConnection_(FTPSClient.java:494)
   at org.apache.commons.net.ftp.FTPClient.listNames(FTPClient.java:1950)
   at org.apache.commons.net.ftp.FTPClient.listNames(FTPClient.java:1996)
   at 
 fr.enovacom.eai.actions.dynamiques.protocole.ftp.FTPGet.testFTPS(FTPGet.java:379)
   at 
 fr.enovacom.eai.actions.dynamiques.protocole.ftp.FTPGet.main(FTPGet.java:401)
 This doesn't occur on passive mode.
 The only way to make it work is to set a keyManager although there is no need 
 for a client authentication.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (NET-326) A KeyManager is required when the protection level is set to 'P' with FTPSClient on active mode

2011-03-13 Thread Bogdan Drozdowski (JIRA)


[ 
https://issues.apache.org/jira/browse/NET-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13006205#comment-13006205
 ] 

Bogdan Drozdowski commented on NET-326:
---

isClient/ServerTrusted(): I believe we don't need these anymore. I left them 
because the code I've found on the 'net used them and I figured these may be 
required for backwards-comaptibility and this was my only reason. Now I'm 
thining that the backward-compatible version perhaps required classes from 
javax.security.cert (instead of the new java.security.cert), so this 
compatibility may not be retained anyway.

checkServertrusted(): wasn't commented-out in FTPSTrustManager, but since we're 
accepting everything, I'm not even validating. Validating the certificates 
could cause Exceptions, so we could validate not all certificates. What to do 
is the right question. If the server certificate has expired or is self-signed 
or is not signed by a certificate a user has in his/her trust store, should we 
reject it even if it would provide encryption?

Yes, the accept-all TrustManager looks like the other (except for the disabled 
code, perhaps). It came from the Web, while POP3TrustManager and 
SMTPSTrustManager came from the FTPSTrustManager. I didn't think back then that 
these could be combined, I kept my classes in the packages I modified. But 
you're right: at this point we're duplicating code, so these certainly can be 
combined. And there wouldn't be need for the anonymous class in the 
SSLContextsFactory any more.

 A KeyManager is required when the protection level is set to 'P' with 
 FTPSClient on active mode
 ---

 Key: NET-326
 URL: https://issues.apache.org/jira/browse/NET-326
 Project: Commons Net
  Issue Type: Bug
  Components: FTP
Affects Versions: 2.0
 Environment: Windows XP profesional service pack 2, Java Java 
 1.6.0_12-b04 
Reporter: Terence Dudouit
 Attachments: SSLContextsFactory.java


 Using a simple FTPS client that list a directory, when execPROT(P) is set 
 and the active mode is on, the following exception is thrown :
 javax.net.ssl.SSLException: No available certificate or key corresponds to 
 the SSL cipher suites which are enabled.
   at 
 com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.checkEnabledSuites(SSLServerSocketImpl.java:303)
   at 
 com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.accept(SSLServerSocketImpl.java:253)
   at 
 org.apache.commons.net.ftp.FTPClient._openDataConnection_(FTPClient.java:489)
   at 
 org.apache.commons.net.ftp.FTPSClient._openDataConnection_(FTPSClient.java:494)
   at org.apache.commons.net.ftp.FTPClient.listNames(FTPClient.java:1950)
   at org.apache.commons.net.ftp.FTPClient.listNames(FTPClient.java:1996)
   at 
 fr.enovacom.eai.actions.dynamiques.protocole.ftp.FTPGet.testFTPS(FTPGet.java:379)
   at 
 fr.enovacom.eai.actions.dynamiques.protocole.ftp.FTPGet.main(FTPGet.java:401)
 This doesn't occur on passive mode.
 The only way to make it work is to set a keyManager although there is no need 
 for a client authentication.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (NET-326) A KeyManager is required when the protection level is set to 'P' with FTPSClient on active mode

2011-03-11 Thread Bogdan Drozdowski (JIRA)


[ 
https://issues.apache.org/jira/browse/NET-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13005711#comment-13005711
 ] 

Bogdan Drozdowski commented on NET-326:
---

I think this could be done, but remember that there are a few parameters in the 
code, as you can see:
* the protocol
* the Provider or a provider String (for SSLContext.getInstance(), not used 
here)
* the KeyManagerFactory type
* the KeyStore type
* the filename of the KeyStore
* the password to the KeyStore
* the TrustManager
* a SecureRandom instance (the null parameter in ctx.init() above)

It ceratinly would be possible to create a few overloaded methods that take 
different number of parameters from the above list. If a parameter is null or 
not present in some version of the utility method, use the one from the code 
above.

It would be easier for users, because in the simplest version they would only 
need to create a keystore and provide the filename and password to the method 
and they would get a ready-to-use SSLContext for use in the constructor (so, of 
course, the overloaded methods would have be public static, if they would be 
in FTPSClient). I didn't think of that, but you're right - we should make it 
easier for the users. The simplest version (filename+password) would surely be 
easier to use than writing all the above by hand after, say, an hour of 
browsing the Web. The more parameters will there be in the biggest 
declaration, the better for the more advanced users (less assuming by us, most 
possibilities for the users).

The problem is that supporting all combinations of parameters would probably 
produce many methods. These would probably have to be put in a separate module. 
The minimum is one method (with all the parameters passed from outside), but it 
would be hard to use, so the real minimum should be 2 methods (one with all the 
parameters and one just with the filename and the password).

Conclusion: yes, there is a point in implementing this. Perhaps even not only 
in the ftp package, but somewhere above, because, in theory, even POP3, SMTP 
and other servers where SSL/TLS is used, could require user authentication by 
certificate (apart from the password later on).

 A KeyManager is required when the protection level is set to 'P' with 
 FTPSClient on active mode
 ---

 Key: NET-326
 URL: https://issues.apache.org/jira/browse/NET-326
 Project: Commons Net
  Issue Type: Bug
  Components: FTP
Affects Versions: 2.0
 Environment: Windows XP profesional service pack 2, Java Java 
 1.6.0_12-b04 
Reporter: Terence Dudouit

 Using a simple FTPS client that list a directory, when execPROT(P) is set 
 and the active mode is on, the following exception is thrown :
 javax.net.ssl.SSLException: No available certificate or key corresponds to 
 the SSL cipher suites which are enabled.
   at 
 com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.checkEnabledSuites(SSLServerSocketImpl.java:303)
   at 
 com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.accept(SSLServerSocketImpl.java:253)
   at 
 org.apache.commons.net.ftp.FTPClient._openDataConnection_(FTPClient.java:489)
   at 
 org.apache.commons.net.ftp.FTPSClient._openDataConnection_(FTPSClient.java:494)
   at org.apache.commons.net.ftp.FTPClient.listNames(FTPClient.java:1950)
   at org.apache.commons.net.ftp.FTPClient.listNames(FTPClient.java:1996)
   at 
 fr.enovacom.eai.actions.dynamiques.protocole.ftp.FTPGet.testFTPS(FTPGet.java:379)
   at 
 fr.enovacom.eai.actions.dynamiques.protocole.ftp.FTPGet.main(FTPGet.java:401)
 This doesn't occur on passive mode.
 The only way to make it work is to set a keyManager although there is no need 
 for a client authentication.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (NET-326) A KeyManager is required when the protection level is set to 'P' with FTPSClient on active mode

2011-03-10 Thread Bogdan Drozdowski (JIRA)


[ 
https://issues.apache.org/jira/browse/NET-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13005100#comment-13005100
 ] 

Bogdan Drozdowski commented on NET-326:
---

Terence, you didn't show us:
* your code
* the way you're running your code
* the server's configuration.

Since you're saying that a KeyManager is required, I'm guessing that the FTP 
server connecting to you in active mode as a client requires you to provide 
your certificate/key. Since there's no default certificate, the connection 
fails. If this is true, then to reproduce this (if anyone's interested):
* install vsftpd (the easiest, I guess) and set in the config file:
** require_ssl_reuse=no
** ssl_enable=yes
** ssl_sslv3=yes
** ssl_tlsv1=yes
** rsa_cert_file=/path/to/your_certificate_and_key_file
** ssl_request_cert=yes
** require_cert=yes
* run the following code:
{code}
FTPSClient c = new FTPSClient ();
c.connect (127.0.0.1, 21);
c.enterLocalActiveMode();
System.out.println (c.getReplyString());
c.login (login, password);

System.out.println (c.getReplyString());
c.execPROT (P);
System.out.println (c.getReplyString());
String[] names = c.listNames();
{code}

Now, to the point: for this to work automatically, the FTPSClient class would 
have to have all the possible key/certificates. Because of the number of these, 
this is impossible to have. The solution is the FTPSClient constructor with the 
SSLContext parameter. A quick search on the Web (with the errors as the search 
term) made me produce the following code:
{code}
private static X509TrustManager s_x509TrustManager;
static {
s_x509TrustManager = new X509TrustManager() {
public java.security.cert.X509Certificate[] getAcceptedIssuers() {
return new java.security.cert.X509Certificate[] {}; }
public boolean isClientTrusted(java.security.cert.X509Certificate[] 
chain) { return true; }
public boolean isServerTrusted(java.security.cert.X509Certificate[] 
chain) { return true; }
public void checkServerTrusted(java.security.cert.X509Certificate[] 
certificates, String authType)
{}
public void checkClientTrusted(java.security.cert.X509Certificate[] 
certificates, String authType) {}
};
}

private static void testFTPS () throws Exception
{
SSLContext ctx;
KeyManagerFactory kmf;
KeyStore ks;
char[] passphrase = aa.toCharArray();

ctx = SSLContext.getInstance(TLS);
kmf = KeyManagerFactory.getInstance(SunX509);
ks = KeyStore.getInstance(JKS);

ks.load(new FileInputStream(keystore), passphrase);

kmf.init(ks, passphrase);
ctx.init(kmf.getKeyManagers(), new X509TrustManager[] 
{s_x509TrustManager}, null);

FTPSClient c = new FTPSClient (ctx);
c.connect (127.0.0.1, 21);
c.enterLocalActiveMode();
System.out.println (c.getReplyString());
c.login (login, password);

System.out.println (c.getReplyString());
c.execPROT (P);
System.out.println (c.getReplyString());
String[] names = c.listNames();
}
{code}
This code *works* when connecting to *the same* vsftpd server as before (when 
the previous code caused an exception). To run this code, add the following 
command-line options to java (don't know if still required actually, but 
won't hurt):
* -Djavax.net.ssl.trustStore=truststore
* -Djavax.net.ssl.trustStorePassword=aa

Please read the [JSSE Reference 
Guide|http://download.oracle.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html],
 especially the Code Examples section. That's where I got most of the 
information I needed (especially about creating the keystores in files: 
keystore used by the code, and truststore used on the command-line). I 
think that only a certificate for localhost is required, but just in case, 
I've also added a certificate for my hostname in the keystores.

Furthermore, if there's a KeyManager missing, you can always install your own 
with the FTPSClient.setKeyManager method.

 A KeyManager is required when the protection level is set to 'P' with 
 FTPSClient on active mode
 ---

 Key: NET-326
 URL: https://issues.apache.org/jira/browse/NET-326
 Project: Commons Net
  Issue Type: Bug
  Components: FTP
Affects Versions: 2.0
 Environment: Windows XP profesional service pack 2, Java Java 
 1.6.0_12-b04 
Reporter: Terence Dudouit

 Using a simple FTPS client that list a directory, when execPROT(P) is set 
 and the active mode is on, the following exception is thrown :
 javax.net.ssl.SSLException: No available certificate or key corresponds to 
 the SSL cipher suites which are enabled.
   at

[jira] Updated: (NET-327) Unconnected sockets not implemented when using FTPSClient

2011-03-10 Thread Bogdan Drozdowski (JIRA)

[
https://issues.apache.org/jira/browse/NET-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Bogdan Drozdowski updated NET-327:
--

Attachment: ftps-reconn.diff

A code sample would be nice. But I've managed to do my own: executing the
sequence connect, execPROT(P), login, disconnect twice on the same client
instance causes the error. My patch fixes this issue - it overrides the
disconnect() method of FTPClient in FTPSClient to re-set the SocketFactories
(null is allowed, because the SocketClient knows how to deal with it). Thanks
goes to Bengt Rodehav
(http://www.mail-archive.com/user@commons.apache.org/msg04935.html) for
pointing this out.

Unconnected sockets not implemented when using FTPSClient
---

Key: NET-327
URL: https://issues.apache.org/jira/browse/NET-327
Project: Commons Net
Issue Type: Bug
Components: FTP
Affects Versions: 2.0
Environment: Windows XP SP3, Java 1.6.0_18, Apache Karaf 1.6.0
Reporter: Bengt Rodehav
Attachments: ftps-reconn.diff

I'm using Apache Camel as an integration platform. Specifically, at the
moment, I depend on the ftp/ftps/sftp support in the camel-ftp component.
Under the hood Camel uses Commons Net for ftp and ftps support.
Recently, the camel-ftp component was enhanced (on my request) with the
possibility to use a secure data channel. This is accomplished by using the
execProt() (and execPsbz()) method in class FTPSClient.
However, later on (in case Camel needs to reconnect), one of the connect()
methods in the base class to FTPSClient is called. Unfortunately all the
connect methods first create an unconnected socket and then tries to connect
it. The connection factory now associated with the FTPSClient then throws an
exception stating: Unconnected sockets not implemented.
It seems like the FTPSClient does not support re-connect once it has
entered secure communications mode.
See also: http://www.mail-archive.com/user@commons.apache.org/msg04933.html
and http://www.mail-archive.com/users@camel.apache.org/msg08732.html

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (NET-314) The FTP client should autodetect the control encoding.

2011-03-08 Thread Bogdan Drozdowski (JIRA)

[
https://issues.apache.org/jira/browse/NET-314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Bogdan Drozdowski updated NET-314:
--

Attachment: ftp-autodetect-utf.diff

I believe the only non-ASCII encoding permitted is UTF-8
(http://tools.ietf.org/html/rfc2640), this is detected by sending the FEAT
command and looking for UTF8 in the response. The attached file does exactly
this, right after the connection (original server greeting saved restored
later). The autodetection is user-controlled.

The FTP client should autodetect the control encoding.
--

Key: NET-314
URL: https://issues.apache.org/jira/browse/NET-314
Project: Commons Net
Issue Type: Improvement
Components: FTP
Affects Versions: 1.4
Environment: Java client using FTP through VFS to connect to a Java
(Alfresco's) FTP server
Reporter: Tom
Attachments: ftp-autodetect-utf.diff

The Alfresco FTP server uses UTF8 for the control encoding. FTPClient can be
set to use UTF8, but VFS does not expose that
(https://issues.apache.org/jira/browse/VFS-305) and needs to be modified to
fix this. But that is not the issue here; FileZilla is able to automatically
detect that Alfresco's FTP server is using UTF8. So apparantly the server is
somehow communicating this to the client. Being able to automatically set the
encoding, would greately improve the out-of-the-box quality of the FTP
component.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (NET-258) Implement A Keepalive Mechanism

2011-03-04 Thread Bogdan Drozdowski (JIRA)


[ 
https://issues.apache.org/jira/browse/NET-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13002575#comment-13002575
 ] 

Bogdan Drozdowski commented on NET-258:
---

Yes, you were lucky to find both types of servers that easily. I'm glad 
everything works.

Unfortunately, I don't have a router that looks into the traffic and handles 
FTP connections. I don't think that such a router would disconnect the 
connection after a timeout (it should be the server's job to do this), but I 
know that routes that interfere with FTP exist.

The only thing that is left to do is wait for user complaints (if there will be 
any). :)

 Implement A Keepalive Mechanism
 ---

 Key: NET-258
 URL: https://issues.apache.org/jira/browse/NET-258
 Project: Commons Net
  Issue Type: Improvement
  Components: FTP
Affects Versions: 2.0
Reporter: Rory Winston
 Fix For: 3.0

 Attachments: ftp-keepalive.diff


 For routers/firewalls that terminate idle connections, a separate heartbeat 
 mechanism may need to be implemented to keep the control connection active.
 Some potential issues:
 * Synchronization between a heartbeat write and a __getReply() on an active 
 control connection command;
 * Should use the NOOP command as a heartbeat signal;
 * Make the timeout configurable;
 * Default SocketImpl::setKeepAlive() wont do here.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (NET-258) Implement A Keepalive Mechanism

2011-03-03 Thread Bogdan Drozdowski (JIRA)


[ 
https://issues.apache.org/jira/browse/NET-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13001955#comment-13001955
 ] 

Bogdan Drozdowski commented on NET-258:
---

Quite a change, I must say. If the timeouts are set correctly by the user, 
looks fine to me (should work; no obvious problems spotted). Nice work!

 Implement A Keepalive Mechanism
 ---

 Key: NET-258
 URL: https://issues.apache.org/jira/browse/NET-258
 Project: Commons Net
  Issue Type: Improvement
  Components: FTP
Affects Versions: 2.0
Reporter: Rory Winston
 Fix For: 3.0

 Attachments: ftp-keepalive.diff


 For routers/firewalls that terminate idle connections, a separate heartbeat 
 mechanism may need to be implemented to keep the control connection active.
 Some potential issues:
 * Synchronization between a heartbeat write and a __getReply() on an active 
 control connection command;
 * Should use the NOOP command as a heartbeat signal;
 * Make the timeout configurable;
 * Default SocketImpl::setKeepAlive() wont do here.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (NET-258) Implement A Keepalive Mechanism

2011-02-23 Thread Bogdan Drozdowski (JIRA)

[
https://issues.apache.org/jira/browse/NET-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12998359#comment-12998359
]

Bogdan Drozdowski commented on NET-258:
---

The timeouts don't have to be the same order - if the control timeout is 30
seconds, but the data timeout is 10 minutes, we have the same problem. Yes,
it's not something like 1ms vs. 100 minutes, but generally if the control
timeout is less than the data timeout, there is a problem. Not only with the
socket timeout itself, but the server-side timeout (the higher-level timeout),
too.

I don't see how synchronizing a command and its reply would prevent the NOOPs
from being sent, assuming everything is working fine. The server sends a reply
immediately, so we leave the synchronized method as soon as we get the reply
(which is usually soon). Even for RETR/STOR/LIST/... the server first sends a
150 (which makes us leave __getReply() and sendCommand()) and after the
transfer the server sends a 226. Util.copyStream() (the long-lasting operation)
is called outside of the synchronized block (synchronization is in
_openDataConnection_()). CompletePendingCommand() is left unsynchronized right
now, however.

I'm not saying no to sending NOOPs only during transfers. On the contrary,
it's a good solution, because we have everything under control. But the
user-settable and server timeouts make me think that we need something working
independently of the transfer-handling thread.

Implement A Keepalive Mechanism
---

Key: NET-258
URL: https://issues.apache.org/jira/browse/NET-258
Project: Commons Net
Issue Type: Improvement
Affects Versions: 2.0
Reporter: Rory Winston
Assignee: Rory Winston
Attachments: ftp-keepalive.diff

For routers/firewalls that terminate idle connections, a separate heartbeat
mechanism may need to be implemented to keep the control connection active.
Some potential issues:
* Synchronization between a heartbeat write and a __getReply() on an active
control connection command;
* Should use the NOOP command as a heartbeat signal;
* Make the timeout configurable;
* Default SocketImpl::setKeepAlive() wont do here.

--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (NET-258) Implement A Keepalive Mechanism

2011-02-22 Thread Bogdan Drozdowski (JIRA)

[
https://issues.apache.org/jira/browse/NET-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12997785#comment-12997785
]

Bogdan Drozdowski commented on NET-258:
---

These apply mainly to the PUT/GET (or STOR/RETR), but not only. I can imagine a
user that doesn't constantly send data, an issue of type I'm not sending
anything right now, but I may need to in 5 minutes, so let's not disconnect.

The listener method is nice, but if the user sets the timeout to 10 or 20
minutes, it won't do any good. This is it's only problem, I think. This is why
a Timer/ThreadExecutor would be requierd, and this leads to the second method.

Now the separate thread method: if we imlpement a mechanism that the user can
start and stop, it doesn't need to be synchronized with GET/PUT, although some
general synchronization (like making sendCommand() synchronized) would be
recommended. If sendCommand() is synchronized, readLine() would never get
called by different threads at the same time. Even if we send NOOPs only on our
threads, this wouldn't stop the user from interfering with us by launching a
new thread that sends commands or does anything else (including a user-created
keepalive mechanism). Now, if sendCommand() is synchronized, so is
__getReply(), so not only it could be called by only one thread at a time, but
the command-reply pairs wouldn't get messed. The questions are: is this true (I
may be missing something) and is this enough?

Implement A Keepalive Mechanism
---

--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (NET-258) Implement A Keepalive Mechanism

2011-02-17 Thread Bogdan Drozdowski (JIRA)

[
https://issues.apache.org/jira/browse/NET-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12995795#comment-12995795
]

Bogdan Drozdowski commented on NET-258:
---

You're absolutely right about the different threads updating/reading the same
data.

Yes, we could have a single Thread with a loop and make all the command sending
on that thread. If the user enabled keepalives, the thread would periodically
send the NOOP and wait for the answer. The command-sending methods would have
to block until the reply has been received or an Exception occurs (just like
they do now).

The java.util.concurrent.Executors class looks nice, especially the
newSingleThreadExecutor() and newSingleThreadScheduledExecutor() methods. The
get() method of the Future objects returned from submit() would allow us to
wait for the task to complete without a loop (which would require another
volatile boolean, for example).

This is, however, a serious code change. It would probably had to be done on
the base class, FTP, not on the FTPClient class, so this mechanism doesn't get
passed. Something could be broken by this, for example how to return
IOExceptions or how to know if an ExecutionException we caught should be turned
into an IOException or perhaps into something else, or ignored? I don't know if
this idea with Executors is good after all, perhaps there will be a better
solution. I know this solution and I know it works, but I'm starting to think
this may not be the thing we need. Just another solution to think about.

Implement A Keepalive Mechanism
---

--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (NET-258) Implement A Keepalive Mechanism

2011-02-12 Thread Bogdan Drozdowski (JIRA)

[
https://issues.apache.org/jira/browse/NET-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12993951#comment-12993951
]

Bogdan Drozdowski commented on NET-258:
---

Yes, the keepalive thread could see the end-of-transfer message, but then
completePendingCommand() would see the reply to the NOOP, which is always
positive (as the NOOP is mandatory to implement), so it probably wouldn't choke
on this. Now, if the code would be re-written to expect exactly 226, we have a
problem.

Is there something particular in the thread-safety we need to worry about?
We're assuming that the thread is launched only when the user has no commands
to send. So, the input and output buffers (on the control channel) won't have
any interleaved data from different threads. If we assume that the thread is
used as it was meant to be used (which means not sending any commands while
it's running), then I don't know if anything could happen. The server is
passive - it's the client who sends commands and since the client isn't
sending any (the assumption when running the thread), nothing will appear on
the control channel. Furthermore, no other methods or fields are used. Perhaps
the only thing that could happen is a disconnection warning (code 421), but the
thread would catch it and terminate.

If the user sends other commands while the thread is running - then yes, we
could get a mess like assigning wrong replies to commands sent. But it wouldn't
be our problem, because the mechanism wasn't assumed to work like this (it's
the user that is using the client incorrectly) and this won't work.

I don't know what will happen when different threads access the client and send
commands even with the current code, not to mention the patch. If we want to be
safe under all circumstances, work every time (even if the user wants to break
the program), correctly queue the replies and commands, we need a very
different solution - this patch won't make this happen. This is a simple
example solution (perhaps it's what the users are doing already) and it's
manually-started, so it won't harm existing code. To make the whole thing
perfect, perhaps a bigger refactoring would be required, but right now I
haven't got an idea how to do it well (both queues of the commands and replies,
with the replies returned immediately to the caller).

Implement A Keepalive Mechanism
---

--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (NET-356) [SMTP] [Solution] The SMTP client does not support SSL/TLS connections

2011-02-12 Thread Bogdan Drozdowski (JIRA)

[SMTP] [Solution] The SMTP client does not support SSL/TLS connections
--

 Key: NET-356
 URL: https://issues.apache.org/jira/browse/NET-356
 Project: Commons Net
  Issue Type: New Feature
  Components: SMTP
Reporter: Bogdan Drozdowski
Priority: Minor


The SMTPClient class does not support automatic SSL negotiation when connecting 
to the SMTPS port and it does not support TLS negotiation when connecting to 
the standard SMTP port.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (NET-357) [POP3] [Solution] The POP3 client does not support SSL/TLS connections

2011-02-12 Thread Bogdan Drozdowski (JIRA)

[POP3] [Solution] The POP3 client does not support SSL/TLS connections
--

 Key: NET-357
 URL: https://issues.apache.org/jira/browse/NET-357
 Project: Commons Net
  Issue Type: New Feature
  Components: POP3
Reporter: Bogdan Drozdowski
Priority: Minor


The POP3Client class does not support automatic SSL negotiation when connecting 
to the POP3S port and it does not support TLS negotiation when connecting to 
the standard POP3 port.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (NET-258) Implement A Keepalive Mechanism

2011-02-11 Thread Bogdan Drozdowski (JIRA)

[
https://issues.apache.org/jira/browse/NET-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12993578#comment-12993578
]

Bogdan Drozdowski commented on NET-258:
---

Right. Volatile - yes, you're correct - I forgot that. About the rest: sending
NOOPs does nothing to the data transfer (theoretically even closing the control
connection politely does nothing). The data transfer is done by
Input/OutputStreams, as far as I can see. So we have one thread reading/writing
and the other sending NOOPs. The keepalive thread is not started automatically.
The user of the class decides if the thread is to be run and when should it be
stopped. Worker thread is a good idea, but the problem is that we need a reply
immediately, so we can't just queue the command, because it could break the
getReply methods. The intention of the patch is that the command sender knows
that he/she won't send any commands in the nearest future, so he/she launches
the thread. So if any threads the user has won't send any commands, the user
may start the thread. I'm not trying to outsmart anything and guess if we
should interfere or not. This is just a small solution for a start
.

Implement A Keepalive Mechanism
---

--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (NET-258) Implement A Keepalive Mechanism

2011-02-10 Thread Bogdan Drozdowski (JIRA)


 [ 
https://issues.apache.org/jira/browse/NET-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bogdan Drozdowski updated NET-258:
--

Attachment: ftp-keepalive.diff

My ftp-keepalive patch provides this capability. Use startKeepAlive() to start 
a new keep-alive thread, stopKeepAlive() to stop it, setKeepAlivePeriod(int 
millis) to set the timeout between keepalive messages and getKeepAlivePeriod() 
to read it. The thread sends NOOP commands. Tested a little, seems to work.

 Implement A Keepalive Mechanism
 ---

 Key: NET-258
 URL: https://issues.apache.org/jira/browse/NET-258
 Project: Commons Net
  Issue Type: Improvement
Affects Versions: 2.0
Reporter: Rory Winston
Assignee: Rory Winston
 Attachments: ftp-keepalive.diff


 For routers/firewalls that terminate idle connections, a separate heartbeat 
 mechanism may need to be implemented to keep the control connection active.
 Some potential issues:
 * Synchronization between a heartbeat write and a __getReply() on an active 
 control connection command;
 * Should use the NOOP command as a heartbeat signal;
 * Make the timeout configurable;
 * Default SocketImpl::setKeepAlive() wont do here.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (NET-350) java.net.SocketException: Broken pipe when calling TelnetClient.sendAYT()

2011-02-07 Thread Bogdan Drozdowski (JIRA)


 [ 
https://issues.apache.org/jira/browse/NET-350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bogdan Drozdowski updated NET-350:
--

Attachment: sockclient-isconn.diff

Try my patch - it introduces more tests that check if the Socket is connected. 
But the only guaranteed way to theck the connection state is to actually use 
the socket. If reading or writing throws an Exception, we know we're not 
connected, and this is exactly what you're doing. SocketClient can't perform 
and read or writes, because it would eat bytes that the cliane was waiting for 
or perform unspecified actions on the server. You're checking the right way and 
you should continue doing it this way. The patch MAY solve something, but on 
the other hand, it may not. No guarantee. Keep using your method (writing and 
testing for I/O exceptions).

 java.net.SocketException: Broken pipe when calling TelnetClient.sendAYT()
 -

 Key: NET-350
 URL: https://issues.apache.org/jira/browse/NET-350
 Project: Commons Net
  Issue Type: Bug
  Components: Telnet
Affects Versions: 2.2
 Environment: Ubuntu 10.10 (x32)
 Java JDK 1.6.0.22
Reporter: Age Bosma
 Attachments: sockclient-isconn.diff


 I'm trying to write some code to have a reliable way to determine if a telnet 
 connection is still available and not closed on the remote server. Even 
 though I first call TelnetClient.isConnected(), the followed 
 TelnetClient.sendAYT() gives me SocketException. The problem occurs when I 
 provide invalid login credentials on purpose when logging in to the telnet 
 server.
 Code snippet:
 {code:java}
 private boolean isConnected() {
 return isConnected(100);
 }
 private boolean isConnected(int timeOut) {
 boolean connected = false;
 if (telnetClient.isConnected()) {
 try {
 connected = telnetClient.sendAYT(timeOut);
 } catch (IOException ex) {
 
 Logger.getLogger(ForceLogin.class.getName()).log(Level.SEVERE, null, ex);
 } catch (IllegalArgumentException ex) {
 
 Logger.getLogger(ForceLogin.class.getName()).log(Level.SEVERE, null, ex);
 } catch (InterruptedException ex) {
 
 Logger.getLogger(ForceLogin.class.getName()).log(Level.SEVERE, null, ex);
 }
 }
 
 System.out.println(Still connected?  + connected);
 return connected;
 }
 {code}
 What I do is execute the following:
 {code:java}
 succesfulLogin = forceLogin.isConnected();
 if (succesfulLogin) {
 succesfulLogin = forceLogin.isConnected(1000);
 }
 {code}
 When I try to fail the telnet login (providing invalid credentials), the 
 first isConnected() call sometimes gives me TRUE, sometimes gives me FALSE. 
 When it's TRUE I want to make sure that we are really still connected using a 
 longer TelnetClient.sendAYT() timeout. This is where the exception occurs.
 Resulting exception:
 {code:java}
 16-Jan-2011 16:44:04 force.ForceLogin isConnected
 SEVERE: null
 java.net.SocketException: Broken pipe
 at java.net.SocketOutputStream.socketWrite0(Native Method)
 at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
 at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
 at 
 java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
 at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)
 at org.apache.commons.net.telnet.Telnet._sendAYT(Telnet.java:1095)
 at 
 org.apache.commons.net.telnet.TelnetClient.sendAYT(TelnetClient.java:206)
 at force.ForceLogin.isConnected(ForceLogin.java:95)
 at force.ForceLogin.main(ForceLogin.java:160)
 {code}

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (NET-347) FTPClient.listFiles throw exception when connect to an IPv6 FTP server

2011-02-07 Thread Bogdan Drozdowski (JIRA)


[ 
https://issues.apache.org/jira/browse/NET-347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12991410#comment-12991410
 ] 

Bogdan Drozdowski commented on NET-347:
---

Is this the code that isn't working? The given code tries to bind to the 
address of the server. The address to bind to must be one of the local 
addresses, not a remote address. If not using NAT, don't set the active 
external IP address or set it to :: (to force IPv6 addressing). If using a NAT, 
set it to the external address of the gateway.

 FTPClient.listFiles throw exception when connect to an IPv6 FTP server
 --

 Key: NET-347
 URL: https://issues.apache.org/jira/browse/NET-347
 Project: Commons Net
  Issue Type: Test
  Components: FTP
 Environment: jdk 1.6, commons-net-2.2.jar
Reporter: jones wen

 If i setup the IPv6 FTP server on localhost, it is OK.
 If the IPv6 FTP server is on saloris 10(external host), FTPClient.listFiles() 
 will throw below exception,
 java.net.BindException: Cannot assign requested address: JVM_Bind
   at java.net.PlainSocketImpl.socketBind(Native Method)
   at java.net.PlainSocketImpl.bind(Unknown Source)
   at java.net.ServerSocket.bind(Unknown Source)
   at java.net.ServerSocket.init(Unknown Source)
   at javax.net.DefaultServerSocketFactory.createServerSocket(Unknown 
 Source)
   at 
 org.apache.commons.net.ftp.FTPClient._openDataConnection_(FTPClient.java:515)
   at 
 org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:2545)
   at 
 org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:2519)
   at org.apache.commons.net.ftp.FTPClient.listFiles(FTPClient.java:2276)
   at org.apache.commons.net.ftp.FTPClient.listFiles(FTPClient.java:2322)
   at FtpTest.main(FtpTest.java:29)
 the test code is,
   FTPClient client = new FTPClient();
   try {
   
 client.connect(Inet6Address.getByName(2010::214:4fff:fe4d:2c4b), 21);
   client.login(abc, abc);
   client.enterLocalActiveMode();
   
 client.setActiveExternalIPAddress(2010::214:4fff:fe4d:2c4b);
   
   FTPFile[] list = client.listFiles();
 if(list != null  list.length  0) {
   for(int i=0; ilist.length; i++) {
   System.out.println(list[i].getName());
   }
   }
   } catch (SocketException e) {
   e.printStackTrace();
   } catch (UnknownHostException e) {
   e.printStackTrace();
   } catch (IOException e) {
   e.printStackTrace();
   }

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (NET-342) Calling retrieveFileStream(fileName) before listFiles() causes ParserInitializationException

2011-02-07 Thread Bogdan Drozdowski (JIRA)


[ 
https://issues.apache.org/jira/browse/NET-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12991468#comment-12991468
 ] 

Bogdan Drozdowski commented on NET-342:
---

This is the way it should be. You have not read the documentation and you 
haven't called client.completePendingCommand() after the file transfer. This 
didn't flush the server replies and messed up the server reply queue in the 
client.

 Calling retrieveFileStream(fileName) before listFiles() causes 
 ParserInitializationException
 

 Key: NET-342
 URL: https://issues.apache.org/jira/browse/NET-342
 Project: Commons Net
  Issue Type: Bug
  Components: FTP
Affects Versions: 2.0
Reporter: L K

 When calling FtpClient.retrieveFileStream(fileName) before 
 FtpClient.listFiles() an 
 org.apache.commons.net.ftp.parser.ParserInitializationException is thrown, 
 giving the message: Unknown parser type: [last console output]
 Works:
 FTPFile[] ftpFiles = client.listFiles();
 InputStream is = client.retrieveFileStream(./test.txt);
 Works:
 client.pwd();
 FTPFile[] ftpFiles = client.listFiles();
 InputStream is = client.retrieveFileStream(./test.txt);
 Does not work:
 InputStream is = client.retrieveFileStream(./test.txt);
 client.pwd();
 FTPFile[] ftpFiles = client.listFiles();
 Output:
 org.apache.commons.net.ftp.parser.ParserInitializationException: Unknown 
 parser type: / is the current directory

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (NET-351) [POP3] [PATCH] APOP authentication fails most of the time

2011-01-31 Thread Bogdan Drozdowski (JIRA)

[POP3] [PATCH] APOP authentication fails most of the time
-

 Key: NET-351
 URL: https://issues.apache.org/jira/browse/NET-351
 Project: Commons Net
  Issue Type: Bug
Reporter: Bogdan Drozdowski


The APOP authentication fails most of the time. Server replying -ERR Incorrect 
parameters and puts no authentication data in the log.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (NET-352) [POP3] [PATCH] SASL PLAIN CRAM-MD5 authentication

2011-01-31 Thread Bogdan Drozdowski (JIRA)

[POP3] [PATCH] SASL PLAIN  CRAM-MD5 authentication
---

 Key: NET-352
 URL: https://issues.apache.org/jira/browse/NET-352
 Project: Commons Net
  Issue Type: New Feature
Reporter: Bogdan Drozdowski
Priority: Minor


The POP3Client does not suppport the SASL PLAIN  CRAM-MD5 authentication 
mechanisms.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (NET-352) [POP3] [PATCH] SASL PLAIN CRAM-MD5 authentication

2011-01-31 Thread Bogdan Drozdowski (JIRA)


 [ 
https://issues.apache.org/jira/browse/NET-352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bogdan Drozdowski updated NET-352:
--

Attachment: ExtendedPOP3Client.java
pop3-ex.diff

The patch introduces new elements required by SASL. The java file should be put 
in the right place, if this patch is accepted. The class in the file extends 
the existing POP3Client class.

 [POP3] [PATCH] SASL PLAIN  CRAM-MD5 authentication
 ---

 Key: NET-352
 URL: https://issues.apache.org/jira/browse/NET-352
 Project: Commons Net
  Issue Type: New Feature
Reporter: Bogdan Drozdowski
Priority: Minor
 Attachments: ExtendedPOP3Client.java, pop3-ex.diff

   Original Estimate: 0h
  Remaining Estimate: 0h

 The POP3Client does not suppport the SASL PLAIN  CRAM-MD5 authentication 
 mechanisms.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (NET-353) [SMTP] [PATCH] The SMTPClient does not support authentication

2011-01-31 Thread Bogdan Drozdowski (JIRA)

[SMTP] [PATCH] The SMTPClient does not support authentication
-

 Key: NET-353
 URL: https://issues.apache.org/jira/browse/NET-353
 Project: Commons Net
  Issue Type: New Feature
Reporter: Bogdan Drozdowski
Priority: Minor


The SMTPClient java class doesn't support any kind of client authentication.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (NET-353) [SMTP] [PATCH] The SMTPClient does not support authentication

2011-01-31 Thread Bogdan Drozdowski (JIRA)


 [ 
https://issues.apache.org/jira/browse/NET-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bogdan Drozdowski updated NET-353:
--

Attachment: AuthenticatingSMTPClient.java

This class implements the SASL PLAIN  CRAM-MD5 and Microsoft LOGIN 
authentication mechanisms. It also provides the AUTH and EHLO commands and 
parsing enhanced status codes.

 [SMTP] [PATCH] The SMTPClient does not support authentication
 -

 Key: NET-353
 URL: https://issues.apache.org/jira/browse/NET-353
 Project: Commons Net
  Issue Type: New Feature
Reporter: Bogdan Drozdowski
Priority: Minor
 Attachments: AuthenticatingSMTPClient.java

   Original Estimate: 0h
  Remaining Estimate: 0h

 The SMTPClient java class doesn't support any kind of client authentication.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

72 matches

Mail list logo