HTTP_CLIENT SEND_HEADER errorCode 0

[cyohn17082]

HTTP_CLIENT SEND_HEADER errorCode 0

  This event is logged in a 908 every 1 to 2 minutes. Anyone know what it means?

[Anonymous]

Craig, that output is generally related to auto-link. Could you please reply with the output of "show version" as well as the "show run" with any passwords or public IPs scrubbed? Thanks

[perkins]

Has this issue been resolved? I also have the same error using GEN3 924 version R12.3.0.SA.E. Thanks.

[bmullar]

                I upgraded a lab NV3430 from R10.3.0.E to R12.3.2 and a NV6355 from R11.12.0.E to R12.3.2 and lost communications with an n-Command MSP server.  On the AOS units I get the error message “HTTP_CLIENT SEND_HEADER errorCode 0” showing up on the CLI.  On the n-Command MSP server, those units would not check in and the FORCE CHECKIN feature fails.

Earlier versions of AOS use Transport Layer Security (TLS) 1.0 which work with n-Command MSP to transfer information.

AOS R12.3.0 and higher have TLS 1.0 disabled which is less secure than TLS 1.2.  The upgrade “disabled” TLS 1.0.  AOS R12.3.0 and higher have TLS 1.2 enabled by default.

n-Command MSP pre 9.1.3 only supported TLS 1.0.  n-Command MSP 9.1.3 and higher support TLS 1.2 along with TLS 1.0.

Since I am using the Huntsville n-Command MSP server running 8.3.1, I had to add the following commands to my AOS devices to make the n-Command MSP check in process work and the FORCE CHECKIN feature work.

!

auto-link https allow-tls1.0

http secure-server allow-tls1.0

!

The recommendation is for a customer to upgrade their n-Command MSP server to 9.1.3 or higher “before” they upgrade their AOS devices to R12.3.x to prevent communication issues.

Hope this helps.

Regards,

Brian

[Anonymous]

Brian,

     We have the same issue with the 1335 POE.  The chassis will check in but then fails to respond to polling etc...  Is this something that could be set to automatically toggle between 1.0 and 1.2 or will this continue to be a setting that requires it to be statically set?

[bmullar]

If the n-Command MSP server version is before 9.1.3, then n-Command MSP only supports TLS 1.0.

If you upgrade your AOS device to R12.3.0, then TLS 1.0 is turned off.

You will need to execute the commands I listed:

!

auto-link https allow-tls1.0

http secure-server allow-tls1.0

!

If you upgrade the n-Command MSP server version to 9.1.3 or later, then n-Command MSP supports TLS 1.0 and 1.2.

If you upgrade your AOS device to R12.3.x or later, then TLS 1.0 is turned off, "but" TLS 1.2 is turned on.

So the AOS R12.3.x or later device will continue to communicate with n-Command MSP 9.1.3 and later, using TLS 1.2.

No additional commands needed.

So upgrade the n-Command MSP server version first.

Then use n-Command MSP to push a firmware upgrade job.

The AOS would continue to check in.

There is no automatic setting as you asked above.

[Anonymous]

I have the same issue and my MSP is running 9.1.5-15007,  devices R12.3.3 and R13.1 get the same error in event logs.

[Anonymous]

My MSP is running on 10.1.3-15772, and I recently upgraded my Gen2 TA9XX chassis to 12.3.1.  This condition persists after allowing TLS1.0.  Is there somehting else that I am missing here?

[cjohnson]

Try making sure you do not have http source-interface set to the wrong interface or disable it all together. i.e.

if

WAN IP is on ppp 1

and

http source-interface gigabit-ethernet 0/1

change to

http source-interface ppp 1

or

no http source-interface gigabit-ethernet 0/1

[hasans]

i have the same same issue