enter image description hereCan someone please help me to solve the init abort happening from our server side.
Verification tag is always coming as 0 from the transmitter end. But receiver is giving some random value of verification tag.
Please help.
enter image description here
In general, it might happen that endpoint is not able to establish association and send ABORT chunk as response on INIT. This might happen in various situation (such as misconfiguration, when you haven't created endpoint on server side for that association; or lack of resources).
INIT chunk is a bit special (packet that carries it always has verification tag set to zero in common header). INIT chunk also has so called initiate tag - it is basically a verification tag that sender of the INIT chunk expect to see in all the packet it will receive in the scope of this association.
When ABORT is sent as a response on INIT chunk, it will be sent with verification tag set to the initiate tag from INIT. That is exactly what you can see in you wireshark log.
What seems to be strange in you log file is that the sender of ABORT chunk does not follow RFC 4960 in respect to using t-bit.
RFC 4960, chapter 8.4, bullet 3 says:
If, for whatever
reason, the INIT cannot be processed normally and an ABORT has to
be sent in response, the Verification Tag of the packet
containing the ABORT chunk MUST be the Initiate Tag of the
received INIT chunk, and the T bit of the ABORT chunk has to be
set to 0, indicating that the Verification Tag is NOT reflected.
In your case the sender of ABORT chunk is using initiate tag as verification tag (as defined in RFC), but it also sets t-bit to 1 - it is a violation of RFC. Since t-bit is set incorrectly in the packet that carries ABORT chunk, it stop the sender of INIT from handing it correctly. Basically the sender of INIT chunk cannot handle that ABORT.
The sender of ABORT could have also include cause code in ABORT chunk to provide more details about reason of ABORT. However for whatever reasons it hasn't been done and the actual reason of ABORT will remain mystery.
In conclusion:
It is hard to say why the ABORT has been sent based on information
provided. If you can - contact you vendor and suggest to include
cause code in the ABORT chunk as it defined in RFC in order to make
debugging easier.
I would guess that something has not been initialized/configured on you server side, that is why the association is not setup up. I
would start with checking sockets/endpoint configuration on server
side.
The server side of your association (receiver of INIT/sender of ABORT) violates RFC 4960 and set t-bit incorrectly. Because of that
the sender of INIT chunk cannot handle ABORT correctly. I would
suggest to submit a bug report for your server side
implementation/vendor in order get it fixed.
I have a perl code that sends a reminder sms via Net::UCP package. It worked so far, until now, I started to get negative acknowledgement with 02 reason code. The EMI UCP documentation says, it refers to syntax error, but I don't know why. It worked for like 6 months. Here is the sent string:
02/00454/O/51/0036204802483/36303444080/////////////////3/8/5469737A74656C7420DC677966656CFC6E6B21200A0A54E16AE96B6F7A7461746A756B2C20686F6779206C656AE17261746920534D5320737A6F6C67E16C746174E173756E6B20746563686E696B6169206F6B6F6B62F36C206D6567737A3F6E696B2E200A4BE9726AFC6B2C206B69656D656C74656E2066696779656C6A656E2061207AE16C6F676A65677965206C656AE1726174E172612E200A0A5469737A74656C657474656C3A200A42C1562050E96E7AFC677969205A7274////1////1139/////04
And here is what I receive:
02/00022/R/51/N/02//07
My question is where is the syntax error in the sent string? Thanks in advance!
It was the MB parameter that was set to 8. I also noticed that a new message was uploaded that was too long, was longer than 160 characters, so I told the client to change it.
We have an issue with our PayPal Express Checkout integration. We see an error coming back from DoExpressCheckout with code 10004 saying "Transaction refused because of an invalid argument. See additional error messages for details." But the response contains no additional error messages.
This occurs randomly with our integration. It started approximately one month ago and has happened 70 times vs 1430 successful transactions.
It appears to be random. Not tied to any specific amounts, browser type, time of transaction etc. One user could have several failures then try again with the same token and have it go through. Some users have come back 10 minutes later or change browser and it works. Most give up.
I'd appreciate any suggestions, is there a way to retrieve any more debug for this error?
SetExpressCheckout
USER=XXX
PWD=XXX
SIGNATURE=XXX
VERSION=112
METHOD=SetExpressCheckout
ALLOWNOTE=0
ADDROVERRIDE=1
PAYMENTREQUEST_0_SHIPTONAME=Mr X
PAYMENTREQUEST_0_SHIPTOSTREET=Test St
PAYMENTREQUEST_0_SHIPTOSTREET2=
PAYMENTREQUEST_0_SHIPTOCITY=City
PAYMENTREQUEST_0_SHIPTOSTATE=State
PAYMENTREQUEST_0_SHIPTOZIP=5000
PAYMENTREQUEST_0_SHIPTOCOUNTRYCODE=AU
PAYMENTREQUEST_0_SHIPTOPHONENUM=8888888888
RETURNURL=URLA
CANCELURL=URLB
PAYMENTREQUEST_0_PAYMENTACTION=Authorization
PAYMENTREQUEST_0_CURRENCYCODE=AUD
PAYMENTREQUEST_0_AMT=20.9
L_PAYMENTREQUEST_0_NAME0=DOOM PATROL VOL 6 #3
L_PAYMENTREQUEST_0_AMT0=7.95
L_PAYMENTREQUEST_0_NUMBER0=SEP160206
L_PAYMENTREQUEST_0_QTY0=1
L_PAYMENTREQUEST_0_CURRENCYCODE0=AUD
L_PAYMENTREQUEST_0_NAME1=MOTHER PANIC #1
L_PAYMENTREQUEST_0_AMT1=7.95
L_PAYMENTREQUEST_0_NUMBER1=SEP160201
L_PAYMENTREQUEST_0_QTY1=1
L_PAYMENTREQUEST_0_CURRENCYCODE1=AUD
L_PAYMENTREQUEST_0_NAME2=Regular Post (cannot be tracked)
L_PAYMENTREQUEST_0_AMT2=5
L_PAYMENTREQUEST_0_NUMBER2=Freight
L_PAYMENTREQUEST_0_QTY2=1
L_PAYMENTREQUEST_0_CURRENCYCODE2=AUD
GetExpressCheckout
USER=XXX
PWD=XXX
SIGNATURE=XXX
VERSION=2.3
TOKEN=EC-5DX46556HG972093T
METHOD=GetExpressCheckoutDetails
DoExpressCheckout
USER=XXX
PWD=XXX
SIGNATURE=XXX
VERSION=2.3
PAYMENTACTION=Authorization
PAYERID=XXX
TOKEN=EC-5DX46556HG972093T
AMT=20.9
CURRENCYCODE=AUD
METHOD=DoExpressCheckoutPayment
PayPal returns:
TOKEN=EC-5DX46556HG972093T
TIMESTAMP=2016-11-23T10:53:35Z
CORRELATIONID=XXX
ACK=Failure
VERSION=2.3
BUILD=000000
L_ERRORCODE0=10004
L_SHORTMESSAGE0=Internal Error
L_LONGMESSAGE0=Transaction refused because of an invalid argument. See additional error messages for details.
L_SEVERITYCODE0=Error
Error was on PayPals side. If you have the same issue just log a support ticket and magic will happen.
I'm trying to send a SMS using AT commands and after typing the cellphone number it show the CMS: ERROR 302.
What I'm doing:
AT
OK
AT+CMGF=1
OK
AT+CMGS="<3 digit local area code><7 digit cellphone number>"<Enter>
+CMS: ERROR 302
I've found this post: AT+CMGS returns ERROR but couldn't find a solution. Am I typing something wrong? I've changed SMS-encoding to GMS as the post describes.
Try this:
AT
AT+CMGF=1
AT+CSCA="sms tel. service",145
AT+CMGS="tel. number"
text message here
^Z
Some modems need set CSCA (SMS Service Center Address) always.
And look here for a examples and descriptions.
I found out that sending exactly the same AT commands by hand worked, but sending them from a controller did not (with waiting for the correct answers). Getting the 302 error. But then doing all commands a lot slower with waits of 2 secs in between it suddenly started to work. Apparantly the SIM900 needs more time after it answers, or something.
In our Windows C++ application I am using InitializeSecurityContext() client side to open an schannel connection to a server which is running stunnel SSL proxy. My code now works, but only with a hack I would like to eliminate.
I started with this sample code:http://msdn.microsoft.com/en-us/library/aa380536%28v=VS.85%29.aspx
In the sample code, look at SendMsg and ReceiveMsg. The first 4 bytes of any message sent or received indicates the message length. This is fine for the sample, where the server portion of the sample conforms to the same convention.
stunnel does not seem to use this convention. When the client is receiving data during the handshake, how does it know when to stop receiving and make another call to InitializeSecurityContext()?
This is how I structured my code, based on what I could glean from the documentation:
1. call InitializeSecurityContext which returns an output buffer
2. Send output buffer to server
3. Receive response from server
4. call InitializeSecurityContext(server_response) which returns an output buffer
5. if SEC_E_INCOMPLETE_MESSAGE, go back to step 3,
if SEC_I_CONTINUE_NEEDED go back to step 2
I expected InitializeSecurityContext in step 4 to return SEC_E_INCOMPLETE_MESSAGE if not enough data was read from the server in step 3. Instead, I get SEC_I_CONTINUE_NEEDED but an empty output buffer. I have experimented with a few ways to handle this case (e.g. go back to step 3), but none seemed to work and more importantly, I do not see this behavior documented.
In step 3 if I add a loop that receives data until a timeout expires, everything works fine in my test environment. But there must be a more reliable way.
What is the right way to know how much data to receive in step 3?
SChannel is different than the Negotiate security package. You need to receive at least 5 bytes, which is the SSL/TLS record header size:
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
opaque fragment[TLSPlaintext.length];
} TLSPlaintext;
ContentType is 1 byte, ProtocolVersion is 2 bytes, and you have 2 byte record length. Once you read those 5 bytes, SChannel will return SEC_E_INCOMPLETE_MESSAGE and will tell you exactly how many more bytes to expect:
SEC_E_INCOMPLETE_MESSAGE
Data for the whole message was not read from the wire.
When this value is returned, the pInput buffer contains a SecBuffer structure with a BufferType member of SECBUFFER_MISSING. The cbBuffer member of SecBuffer contains a value that indicates the number of additional bytes that the function must read from the client before this function succeeds.
Once you get this output, you know exactly how much to read from the network.
I found the problem.
I found this sample:
http://www.codeproject.com/KB/IP/sslsocket.aspx
I was missing the handling of SECBUFFER_EXTRA (line 987 SslSocket.cpp)
The SChannel SSP returns SEC_E_INCOMPLETE_MESSAGE from both InitializeSecurityContext and DecryptMessage when not enough data is read.
A SECBUFFER_MISSING message type is returned from DecryptMessage with a cbBuffer value of the amount of desired bytes.
But in practice, I did not use the "missing data" value. The documentation indicates the value is not guaranteed to be correct, and is only a hint for developers can use to reduce calls.
InitalizeSecurityContext MSDN doc:
While this number is not always accurate, using it can help improve performance by avoiding multiple calls to this function.
So I unconditionally read more data into the same buffer whenever SEC_E_INCOMPLETE_MESSAGE was returned. Reading multiple bytes at a time from a socket.
Some extra input buffer management was required to append more read data and keep the lengths right. DecryptMessage will modify the input buffers' cbBuffer properties when it fails, which surprised me.
Printing out the buffers and return result after calling InitializeSecurityContext shows the following:
read socket:bytes(5).
InitializeSecurityContext:result(80090318). // SEC_E_INCOMPLETE_MESSAGE
inBuffers[0]:type(2),bytes(5).
inBuffers[1]:type(0),bytes(0). // no indication of missing data
outBuffer[0]:type(2),bytes(0).
read socket:bytes(74).
InitializeSecurityContext:result(00090312). // SEC_I_CONTINUE_NEEDED
inBuffers[0]:type(2),bytes(79). // notice 74 + 5 from before
inBuffers[1]:type(0),bytes(0).
outBuffer[0]:type(2),bytes(0).
And for the DecryptMessage Function, input is always in dataBuf[0], with the rest zeroed.
read socket:bytes(5).
DecryptMessage:len 5, bytes(17030201). // SEC_E_INCOMPLETE_MESSAGE
DecryptMessage:dataBuf[0].BufferType 4, 8 // notice input buffer modified
DecryptMessage:dataBuf[1].BufferType 4, 8
DecryptMessage:dataBuf[2].BufferType 0, 0
DecryptMessage:dataBuf[3].BufferType 0, 0
read socket:bytes(8).
DecryptMessage:len 13, bytes(17030201). // SEC_E_INCOMPLETE_MESSAGE
DecryptMessage:dataBuf[0].BufferType 4, 256
DecryptMessage:dataBuf[1].BufferType 4, 256
DecryptMessage:dataBuf[2].BufferType 0, 0
DecryptMessage:dataBuf[3].BufferType 0, 0
read socket:bytes(256).
DecryptMessage:len 269, bytes(17030201). // SEC_E_OK
We can see my TLS Server peer is sending TLS headers (5 bytes) in one packet, and then the TLS message (8 for Application Data), then the Application Data payload in a third.
You must read some arbitrary amount the first time, and when you receive SEC_E_INCOMPLETE_MESSAGE, you must look in the pInput SecBufferDesc for a SECBUFFER_MISSING and read its cbBuffer to find out how many bytes you are missing.
This problem was doing my head in today, as I was attempting to modify my handshake myself, and having the same problem the other commenters were having, i.e. not finding a SECBUFFER_MISSING. I do not want to interpret the tls packet myself, and I do not want to unconditionally read some unspecified number of bytes. I found the solution to that, so I'm going to address their comments, too.
The confusion here is because the API is confusing. Ordinarily, to read the output of InitializeSecurityContext, you look at the content of the pOutput parameter (as defined in the signature). It's that SecBufferDesc that contains the SECBUFFER_TOKEN etc to pass to AcceptSecurityContext.
However, in the case where InitializeSecurityContext returns SEC_E_INCOMPLETE_MESSAGE, the SECBUFFER_MISSING is returned in the pInput SecBufferDesc, in place of the SECBUFFER_ALERT SecBuffer that was passed in.
The documentation does say this, but not in a way that clearly contrasts this case against the SEC_I_CONTINUE_NEEDED and SEC_E_OK cases.
This answer also applies to AcceptSecurityContext.
From MSDN, I'd presume SEC_E_INCOMPLETE_MESSAGE is returned when not enough data is received from server at the moment. Instead, SEC_I_CONTINUE_NEEDED returned with InBuffers[1] indicating amount of unread data (note that some data is processed and must be skipped) and OutBuffers containing nothing.
So the algorithm is:
If SEC_I_CONTINUE_NEEDED returned, check type of InBuffers[1]
If it is SECBUFFER_EXTRA, handle it (move InBuffers[1].cbBuffer bytes to the beginning of input buffer) and jump to next recv & InitializeSecurityContext iteration
If OutBuffers is not empty, send its contents to server