db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmars...@Sourcery.Org>
Subject [PATCH] Multiple EXCSAT fix
Date Thu, 20 Jan 2005 05:12:35 GMT
Hash: SHA1

Hello All,

The attached patch is to address an issue  with the Network Server
regarding the handling of the EXCSAT codepoint.  Army told me that he
hit this with the C client tests that he is running.

There are three kinds of EXCSAT's we might get

1) Initial Exchange attributes.   For this we need to initialize the
apprequester. Session state is set to ATTEXC (attributes exchanged) then
the AR must follow up with ACCSEC and SECCHK to get the connection.

2) Send of EXCSAT as ping or manager level adjustment. For this we just
ignore the EXCSAT objects that are already set.  JCC doesn't use this,
but it is in DRDA.

3) Send of EXCSAT for connection reset. (see parseEXCSAT2()) This is
treated just like ping and will be followed up
by an ACCSEC request if in fact it is a connection reset.
If we have already exchanged attributes once just
process any new manager levels and return (case 2 and 3 above)
Before the XA checkin, 1 and 2 worked.  After the XA checkin 1 and 3
worked and with this patch 1, 2, and 3 all work.

I had to rearrange the code a bit to do this because in DRDAConnThread,
processCommands() the EXCSAT case just called parseDRDAConnection which
expected the ACCSEC and SECCHK codepoints in the correct order.

As a solution I
1) Moved the handling of the ACCSEC and SECCHK codepoints from
parseDRDAConnection up to  processCommands().

2) Put the security state in the Session object.  The session has
   4 states.

two existed before:
INIT 	- initial state
ATTEXC  - attributes exchanged
	   (After first EXSAT - ACCSEC required)

now there are two new ones:

SECACC   - security accessed (After successful ACCSEC - need SECCHK)
CHKSEC   - checked security. After successful SECCHK and connection.
           no more required security codepoits.

The session.getRequiredSecurityCodepoint() method is used by
process_commands to determine if the next codepoint must be ACCSEC or

Also the patch includes the fix Dan suggested for jdk 131 for
BrokeredPreparedStatent.getStatement(). But how to call
Connection.prepareStatement is still an issue.

Please let me know if you have any questions or issues.

Ran derbynetmats.  Changed some protocol tests that are still on the to
be contributed list.

I will check this in noon tomorrow if there are no objections if Army
gives the all clear with his tests.



Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org


View raw message