tacas username for LMS gets sometimes truncated

[Martin Ermel]

after installing LMS 3.0.1 (solaris) customer observes failed login attempts in ACS log. The username and source ip in the log report points to the LMS server and shows that the username gets truncated.

I am not sure if the reason is wether LMS is just sending the username to fast or if this occurs when the ACS server is under heavy load (perhaps by LMS config collection for approx. 3000 devices).

Does anybody see this behaviour also?

Is there any delay value that can be defined in LMS to slow down login attempts?

[robv]

timing (ie "too fast") would be wierd.

get a 3-way sniffer trace to see if the actual username string is sent by lms as expected at all (e.g. server/app problem), is getting truncated in the auth packet sent to acs (e.g. device ios problem), or if it gets there fine but the acs eats it (acs problem).

if can't solve, farm out to TAC for a patch as necessary, with your findings in-hand to speed things up.

ps - beware server-side TCP checksum offload, it's more often broken than not; in the last year I've had a ton of crap packets due to e.g. broken NIC drivers junking otherwise valid payload.

good luck!

[Martin Ermel]

I solved the issue. The username were indeed sent truncated. The reason was a stale 'Archive Update' and 'CDA' job. Restarting of dmgtd stopped this special 'Archive Update' job and it could be deleted afterwards. This solved the major problem.

I think the reason for the trunkated username was a heavy load on the LMS Server and the NIC. An instance of the job hasn't finished but another instance was started anyway. So this screw up over last days (the server is dealing with around 3k devices).

The CDA job could not be deleted (even not from jobcli) and was constantly reported as 'Never Started' in the output of pdshow across several dmgtd restarts. Finaly I tryed to start it with pdexec and tryed to stopp and delete it afterwards. But this messed it up even more.

Now, in the Job Browser of CS it was listed as 'Running' in the column 'Status' and as 'Canceled' in the column 'Run Status' (after trying to cancle the job from jobcli - before it was 'failed').

I found that there was no CDA.obj in the input directory (var/adm/CSCOpx/files/rme/jobs/cda/) for that job. So I stopped dmgtd and copied the files of another completed CDA job into the input and output directories of the problematic job. After renaming the log file in the output directory and restarting dmgtd the job could be deleted.

perhaps this could be helpful for someone - sometime....