Ldapmavis-mt doesn’t try to open new session to ldap server after inactivity

[sanjmonkey]

Hi Marc,

I noticed in testing, it seems that if the TCP session to the LDAPS server times out / closes due to inactivity, then when the next tacacs client comes along, it doesn’t try to create a new session to LDAPS again, resulting in an ERR response back to client. Would it be possible to check if the connection had closed and to try to reopen it if so? Interested in your thoughts on that

Thanks as always! Really a great project!

Sandy

[MarcJHuber]

Hi Sandy,

alas, it will take a while to add resilience to this. Threading complicates things :-/

Cheers,

Marc

[MarcJHuber]

Hi Sandy,

I've added some recovery code in 6edb2e1a22c511cbfce0b0aa80bc7744e24c7d42.

Cheers,

Marc

[sanjmonkey]

Hi Marc,

I just tried testing this, unfortunately it now doesn’t try to reach out to LDAPS hosts even on first attempt.

I rolled back to previous commit 004679e3fdf7d055bf803748f7e79143c3972108 and LDAPS is working again

[MarcJHuber]

Hi Sandy,

mea culpa ... looks like I didn't test the latest code correctly (wrong binary). The lastest commit should fix this issue.

Thanks,

Marc

[sanjmonkey]

Hi Marc,

Checking latest shows LDAPS is working again, thanks! Still seeing the original behaviour though; if I leave the tacacs server with no client activity until the TCP sessions with LDAPS all timeout (5 mins in my case) and then retry an auth, tacacs server is not trying to reach out to LDAPS

Cheers Sandy

[MarcJHuber]

Hi Sandy,

e4f7ff3aa716b117921fdc94255b453cf39721c8 removes the shared LDAP connection and uses a dedicated one for each thread, so connection timeouts should no longer cause issues.

Cheers,

Marc

[sanjmonkey]

That’s fixed it! Nice! Thank you Marc