ANR0443W after Client update


ADSM.ORG Senior Member
Oct 27, 2003
Reaction score
Stuttgart, Germany
Hello altogether,

after updating most TSM clients to 81.114.000 there were lots of these warnings:
16.08.2022 12:39:53 ANR0443W Protocol error on session 613556 for node Unknown () - invalid "sessType" field found in "Negotiate" verb (offset 26).

In the meantime I updated the clients to, the warnings remain. So I think there is something new in the communication protocol. Fortunately all operations work like before!

Server version has been released a few weeks ago, should I upgrade? Of better wait for the fitst fix?

Thanks for reading :)
Are there any errors in the dsmerrror.log around 16.08.2022 12:39:53 on that client?
What type of client is it? Just regular client for file backup, or a TDP?
I do not find anything peculiar in the client log files. In the server actlog, I cannot even find from which IP address the session has been initiated.
These are regular BA clients. Most sessions are being produced by MAGS backups of our Isilons.
Since the error message in the actlog doesn't show the node_name, likely because the error happens before it identifies itself to the server, maybe you can proceed by process of elimination. Look for nodes that failed or missed their backup schedules and check their logs.
In some client logs I found many GSkit errors, but their timestamps are not corresponding with the protocol errors on the server. Will have to investigate them too. They also appear on Linux clients, which were not updated.
16.08.2022 05:22:00 ANS1579E GSKit-Funktion gsk_secure_soc_init fehlgeschlagen mit 403: GSK_ERROR_NO_CERTIFICATE
16.08.2022 12:39:53 ANR0443W Protocol error on session 613556 for node Unknown () - invalid "sessType" field found in "Negotiate" verb (offset 26).

From the message manual regarding ANR0443W.

"The server detects a protocol error on the specified session because an invalid field has been found in a verb sent from the client node."

Suspect an application, other than TSM, is trying to use a TSM reserve port.
No node name or session , that I have encounter, have been due to network port scanning the TSM Server port.

-Network port scan.
-ID the process that is attempting to use/access/probe/scan the port reserved for TSM
-Config the port monitoring/scan application to avoid probe/scan TSM ports

Good Luck,
Last edited: