What release version of 3.1 are you running for that trace, as I get similar results to the others above, in that it stops working when client set to TLS1.1 so I wondered if a certain versions of 3.1 worked whilst others didn't.   No. AnyConnect, any version, do adapt to the Windows version running. Newest OS versions prevent obsolete TLS versions to be negotiated. ... View more

That is wrong. See Wireshark capture of Client Hello from AnyConnect 3.1.   TLSv1.1 Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.1 (0x0302) Length: 99 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 95 Version: TLS 1.1 (0x0302) Random: 5aad3dc8639ca8ea4944bc71e363602801a4106d5621fe67... Session ID Length: 0 Cipher Suites Length: 14 Cipher Suites (7 suites) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Compression Methods Length: 1 Compression Methods (1 method) Extensions Length: 40 Extension: status_request (len=5) Extension: supported_groups (len=8) Extension: ec_point_formats (len=2) Extension: SessionTicket TLS (len=0) Extension: extended_master_secret (len=0) Extension: renegotiation_info (len=1) ... View more

I think what happened is that I had uploaded the gadget on the master only, and for a period of time the HA system tried to fetch it from the slave. While the FQDN config was pointing to the master, so it was fine. As a side note, there have been a couple more things that didn't worked right after the upgrade: Needed to set again Supervisors permission for dashboards permalinks. We use custom dashboards, something in the data "formatting" has changed, so our application had to be corrected accordingly. Thanks again, Paolo. ... View more

I have tested with 154-3.M6a  got the below log, looks like ls_004 and ls_020 are same for unassigned number. So with 15.4 (3)M ls_004 is returned only when pstn reports unassigned number? Can at least a bug be opened to document the change? Changing API returned codes can break existing applications. ... View more

Is it possible for you to share the " sh version " of both the system. I tried various versions from 12.4(24)T8 to 15.4(3)M2, these all return ls_004. The version that returns ls_020 is 15.4(3)S6a, I suspect it runs on ASR routers in cube HA mode. ... View more

you will see as below log for ls_004. //-1//Dest:/DestStatusFromDiscCause: mapped "unassigned number (1)"(1) to DEST_INVALID_NUMBER(4) Yes, that is what happens on my system: script calls to destination without a dial-peer match fails with ls_004. But on a different system, to which I have no access, in the same situation they fail with ls_020, e message is pritnted about no dial -peer match, and I still don't know why the difference.. ... View more

I think to receive ls_004 you need a dial-peer match, but no number configured. In your case there is no dial peer match for the number you dialed, which is why you got this error. What do you mean with "no number configured"? All my dial-peer have a destination-pattern configured. When for testing on my system I do "show dialplan number XXX ", and the result is "no match", then script calls to XXX fails with ls_004. The ls_020 code comes from the same script running on another system to which I have no access to see what's different. ... View more