[20350] in Kerberos_V5_Development
Re: Race condition while setting password
daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed Feb 2 15:20:09 2022
To: Sushmita Bhattacharya <sushmita.bhattacharya@oracle.com>,
"krbdev@mit.edu"
<krbdev@mit.edu>
From: Greg Hudson <ghudson@mit.edu>
Message-ID: <f74681be-9a82-a1dc-eb56-53dc45790422@mit.edu>
Date: Wed, 2 Feb 2022 15:18:44 -0500
MIME-Version: 1.0
In-Reply-To: <PH0PR10MB47900607BC8891D88BBBD8748B279@PH0PR10MB4790.namprd10.prod.outlook.com>
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On 2/2/22 8:12 AM, Sushmita Bhattacharya wrote:
> Hi,
> With regards to the following issue : https://krbdev.mit.edu/rt/Ticket/Display.html?id=9037 , any suggestions on whether using k5_sendto with NO_UDP as transport strategy, in change_set_password function, can be a valid workaround(in code) for a deployment which is hitting this issue and is not particularly specific about using UDP ?
Yes, that is a simple change and should work fine for a deployment which
can handle kpasswd over TCP (as most should).
Ken wrote:
> But I am puzzled at your problem; is the problem that your client
> implementation doesn't prefer TCP?
In the latest reports of this problem, the client tries TCP, doesn't see
the response, then tries UDP after a second and receives the error, all
before the TCP layer manages to retransmit the response.
As outlined in the ticket, my plan is to try TCP only, and only after a
complete failure, try again with UDP only. But I haven't implemented
that yet.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
