Hi Luis, { I'm kind of new to this app. If you'll give me a thorough description of the problem, I'll have a go at it. A link to some previous bug report is fine. } It is not a bug; it is (at present and for some unknow reason) an architectural limitation of STUNNEL. I simply wish to specify the MSG_OOB flag in my client's C Socket SEND call, or use the (below) sendUrgentData() Java method, and have STUNNEL just faithfully replay it to the destination TCP/IP port. Am I asking too much? Cheers Richard Maher import java.io.BufferedOutputStream; import java.io.BufferedInputStream; import java.io.IOException; import java.net.InetAddress; import java.net.InetSocketAddress; import java.net.Socket; import java.net.UnknownHostException; import java.net.SocketTimeoutException; import java.lang.System; import javax.net.ssl.SSLSocket; import javax.net.ssl.SSLSocketFactory; public class Tier3Socket { public static final String T3ID="T3$"; public static final int USERSIZ=40; public static final int T3IDBUFSIZ=48; public static final int CREDBUFSIZ=80; public static final int CONTIMOUT=3000; public byte [] t3IdBuf; public byte [] readBuf; public byte [] writeBuf; private String host; private int port; private int maxBufSiz; private int bytesIn; private String hostCharSet; private Socket t3Sock; private SSLSocketFactory sockFactory; private BufferedInputStream in; private BufferedOutputStream out; private byte [] outUser; private byte [] outPwd; private byte [] credBuf; private String inMsg; private String stringOut; private boolean sslReqd; Tier3Socket (String host, int port, int maxBufSiz, String hostCharSet, boolean sslReqd) { this.host = host; this.port = port; this.maxBufSiz = maxBufSiz; this.hostCharSet = hostCharSet; this.bytesIn = 0; this.sslReqd = sslReqd; t3IdBuf = new byte[T3IDBUFSIZ]; readBuf = new byte[maxBufSiz]; if (sslReqd) sockFactory = (SSLSocketFactory)SSLSocketFactory.getDefault(); } public void open() throws UnknownHostException, IOException { if (sslReqd) t3Sock = (SSLSocket)sockFactory.createSocket(); else t3Sock = new Socket(); t3Sock.setKeepAlive(true); t3Sock.setReuseAddress(true); t3Sock.setTcpNoDelay(true); t3Sock.connect(new InetSocketAddress(host,port), CONTIMOUT); in = new BufferedInputStream (t3Sock.getInputStream() ,maxBufSiz); out = new BufferedOutputStream (t3Sock.getOutputStream(),maxBufSiz); if (sslReqd) { ((SSLSocket)t3Sock).setUseClientMode(true); try {((SSLSocket)t3Sock).startHandshake();} catch (IOException e) { System.out.println("Failed SSL Handshake"); throw new IOException("Can't SSL on Socket"); } } } public void handShake(String username, String password) throws IOException { credBuf = new byte[CREDBUFSIZ]; outUser = username.getBytes(hostCharSet); System.arraycopy(outUser, 0, credBuf, 0, outUser.length); outPwd = password.getBytes(hostCharSet); System.arraycopy(outPwd, 0, credBuf, USERSIZ, outPwd.length); out.write(credBuf, 0, CREDBUFSIZ); out.flush(); if (in.read(t3IdBuf) < t3IdBuf.length) { System.out.println("Read < " + Integer.toString(t3IdBuf.length) + " bytes"); throw new IOException(); } inMsg = new String(t3IdBuf, 0, 3, hostCharSet); if (!inMsg.equals(T3ID)) { throw new IOException(); } } public void sendUrgentData (int oob) throws IOException { t3Sock.sendUrgentData(oob); } public void setTimeout(int msecs) throws UnknownHostException, IOException { t3Sock.setSoTimeout(msecs); } public void close () throws IOException { if (t3Sock != null && !t3Sock.isClosed()) { try {t3Sock.close();} catch (Exception e) {e.printStackTrace();} } } public void buffMessage (String message) throws IOException { byte [] msg = message.getBytes(hostCharSet); out.write(msg); } public void sendMessage (String message) throws IOException { byte [] msg = message.getBytes(hostCharSet); out.write(msg); flush(); } public void flush () throws IOException { out.flush(); } public int readMessage () throws IOException { return readMessage(readBuf.length); } public int readMessage (int bytes) throws IOException { try { bytesIn = in.read(readBuf, 0, bytes); } catch (SocketTimeoutException e) { return 0; } return bytesIn; } public String getString () throws ArrayIndexOutOfBoundsException { return getString(0, bytesIn); } public String getString (int offset, int length) throws ArrayIndexOutOfBoundsException { if ((offset + length) > bytesIn) { throw new ArrayIndexOutOfBoundsException(); } try { stringOut = new String(readBuf, offset, length, hostCharSet); } catch (Exception e) { return null; } return stringOut; } } ----- Original Message ----- From: "Luis Rodrigo Gallardo Cruz" <[email protected]> To: <[email protected]> Sent: Saturday, September 15, 2007 9:20 AM Subject: Re: [stunnel-users] A series of minor patches from Debian

_______________________________________________ stunnel-users mailing list [email protected] http://stunnel.mirt.net/mailman/listinfo/stunnel-users

Hi Luis, [ I'll look into it. I think you *might* be asking too much, because if you're talking to stunnel the other side might be past a socket type that doesn't allow for oob data (a pipe, for example). Also, I need to find out how this interacts with ssl. ] True, the SSL i/o routines I've seen don't seem to have any provision for handling OOB data. Having said that, the SSL standards that I've also seen clearly state that OOB data *is* part of the specification and *not* just when "inlined". [Anyways, I'll let you know what I find out.] Thanks! Cheers Richard Maher ----- Original Message ----- From: "Luis Rodrigo Gallardo Cruz" <[email protected]> To: <[email protected]> Sent: Saturday, September 15, 2007 9:43 PM Subject: Re: [stunnel-users] A series of minor patches from Debian

_______________________________________________ stunnel-users mailing list [email protected] http://stunnel.mirt.net/mailman/listinfo/stunnel-users

The Debian package of stunnel changed the default location of the binaries, from /usr/sbin to /usr/bin. This is because we consider that stunnel is not an admin only tool, but is useful to regular users (as it does not require root privileges for several common use cases).

I did the same in Cygwin (or maybe the previous packager did; anyway Cygwin puts the main executable in /usr/bin), for the same reason.

On Sat, Sep 22, 2007 at 06:18:29PM +0200, Michal Trojnara wrote:

On Saturday 22 September 2007 07:50, Andrew Schulman wrote:

...

...

The Debian package of stunnel changed the default location of the binaries, from /usr/sbin to /usr/bin. This is because we consider that stunnel is not an admin only tool, but is useful to regular users (as it does not require root privileges for several common use cases).

I did the same in Cygwin (or maybe the previous packager did; anyway Cygwin puts the main executable in /usr/bin), for the same reason.

My comment to all port maintainers, if my opinion as the mainstream author is somehow relevant:

Indeed it is :)

I don't recommend implementing any changes that break mainstream compatibility.

I agree with the idea. Unfortunately, I'm now sort of forced to do this because a) If I don't, I'll be breaking the LSB, and thus, Debian policy. b) The change is already done (indeed, it was done by the previous maintainer quite a while ago). Changing it back now will just bring pointles breakage to users. Actually, the point of my mail was to see if I could stop carrying this divergence, by having the change incorporated here, upstream. I read your answer as saying 'no', and that's fine by me. The change has not been a support burden so far, so I will keep it. That's I think, the correct compromise, as it's Debian's (and not mainstream's) requirements I'm serving with it.

On Sat, Sep 22, 2007 at 09:55:30PM +0200, Michal Trojnara wrote:

On Saturday 22 September 2007 21:04, Luis Rodrigo Gallardo Cruz wrote:

...

a) If I don't, I'll be breaking the LSB, and thus, Debian policy.

Actually, the point of my mail was to see if I could stop carrying this divergence, by having the change incorporated here, upstream. I read your answer as saying 'no', and that's fine by me.

You're not very good at reading my answers. 8-)

Sorry.

In fact I'm likely to be convinced with reasonable argumentation.

To clarify "reasonable": - argumentation "according to LSB section x.y.z" or "this is simple, very useful and unlikely to break portability" usually works;

Ok. Debian policy demands packages comply with the Filesystem Hierarchy Standard 2.3. So does LSB chapter 16. This makes it advisable to comply with it on every Linux and not unreasonable (I think) to comply on every *NIX. FHS specifies that /sbin : System binaries Purpose Utilities used for system administration (and other root-only commands) are stored in /sbin, /usr/sbin, and /usr/local/sbin. /sbin contains binaries essential for booting, restoring, recovering, and/or repairing the system in addition to the binaries in /bin. [18] Programs executed after /usr is known to be mounted (when there are no problems) are generally placed into /usr/sbin. Locally-installed system administration programs should be placed into /usr/ local/sbin. [19] Note [19] reads: Deciding what things go into "sbin" directories is simple: if a normal (not a system administrator) user will ever run it directly, then it must be placed in one of the "bin" directories. Ordinary users should not have to place any of the sbin directories in their path. For example, files such as chfn which users only occasionally use must still be placed in /usr/bin. ping, although it is absolutely necessary for root (network recovery and diagnosis) is often used by users and must live in /bin for that reason. To me (and to the submitter of debian bug report #348862) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=348862 this implies stunnel ought not be in /usr/sbin. OTOH, I have no idea how much this will break compatibility with non-linux systems, or how painful for widespread change it would be.