I want to establish a tls connection between my sim card and a server in TLS-PSK mode. to achive this, as far as I understood, First I have to send a push command to open a BIP channel, then establish a CAT_TP link by sending another push command and then sim card will start the TLS handshake. So first I want to send a push command to my sim card to open a BIP channel. To do this, the push command will be OPEN CHANNEL command. But first I'm testing this process by sending the OPEN CHANNEL command to sim card via sim card reader to see how it works. I have a sample file which I'm following that first sends an envelope SMS-PP with the following content:
81488346 \
84 44\ ;Connection parameter tag
81 03 014001\ ;Command details TLV
82 02 8182\ ;Device identities TLV
35 01 03\ ;Bearer description TLV: default
39 02 0514\ ;Buffer size TLV
47 14 13696E7465726E65742D656E7472657072697365\ ;Network Access Name
0D 07 xxxxxxxxxxxxxx\ ;login name
0D 07 xxxxxxxxxxxxxx\ ;password
3C 03 021964\ ; UICC/terminal interface port number
3E 05 xxxxxxxxxx ;IP address
in sample file it ciphers the above content by sim card's keys and it's RAM TAR value and sends the ciphered data by an envelope command like this:
Command : 80 C2 00 00 8A
Input Data : D1 81 87 02 02 82 81 06 02 80 01 8B 7D 40 05 81
: 12 50 F3 96 F6 22 22 22 22 22 22 22 6D 02 70 00
: 00 68 15 16 39 12 12 00 00 01 F0 BD C0 49 B4 0C
: EB A9 7C 4B 04 32 17 BE A7 2F DA AC 70 93 36 73
: 83 FD AC 64 CA 9B 34 9C 2B E6 31 24 A0 D5 11 09
: 00 3E E3 F5 43 4B 55 77 98 E5 08 40 A4 CE A9 52
: 3E E1 38 6B 44 AC 73 1E 3B CD 49 32 92 B2 C3 22
: 25 02 68 90 FD F5 06 23 97 0D BD 5B 1D DE 25 F1
: FD 4C 75 C8 37 AC B0 15 05 25
Then it fetches the push sms via a FETCH command and after that get the terminal response with TERMINAL RESPONSE command to see if everything went ok. and finally fetches the open channel with the FETCH command and it says once OPEN CHANNEL is done, card sends CLIENT HELLO to the server to start the TLS handshake.
Now I want to implement this but at the first step, where I should send the envelope, I expect to get 9146 as status word which means everything was ok. but I get 6200 which means "State of non-volatile memory is unchanged".
Why do I get this respnse? And basically what is the proper way to open a BIP channel and then stablish a CAT-TP link?
You should first send the TERMINAL PROFILE command. With this command, you'll let the UICC know what the terminal is capable of. In this command, you should indicate that the terminal is capable of handling PROACTIVE commands. You can read more about this in ETSI TS 102223
Related
I am trying to implement a SSL client into my IoT project. I have copied the SSL_Client example I found in STM32Cube_FW_F7_V1.15.0 into my project and was able to compile succesfully. However the SSL handshake fails with -0x7780 MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE. I attach the console debug output:
. Seeding the random number generator... ok
. Loading the CA root certificate ... ok (1 skipped)
. Connecting to tcp/www.google.de/443... ok
. Setting up the SSL/TLS structure... ok
. Performing the SSL/TLS handshake...=> handshake
client state: 0
=> flush output
<= flush output
client state: 1
=> flush output
<= flush output
=> write client hello
client hello, max version: [3:3]
dumping 'client hello, random bytes' (32 bytes)
0000: 88 d9 c4 b1 4f 82 ef a2 74 80 5c 6e 3f c4 29 ca ....O...t.\n?.).
0010: a4 8d 61 2b f6 37 ec 93 39 cb 7d d0 39 5a 67 9b ..a+.7..9.}.9Zg.
client hello, session id len.: 0
dumping 'client hello, session id' (0 bytes)
client hello, add ciphersuite: c02b
client hello, add ciphersuite: c031
client hello, add ciphersuite: c02d
client hello, add ciphersuite: 00a8
client hello, got 4 ciphersuites (excluding SCSVs)
adding EMPTY_RENEGOTIATION_INFO_SCSV
client hello, compress len.: 1
client hello, compress alg.: 0
client hello, adding server name extension: mbed TLS Server 1
client hello, adding signature_algorithms extension
client hello, adding supported_elliptic_curves extension
client hello, adding supported_point_formats extension
client hello, adding encrypt_then_mac extension
client hello, adding extended_master_secret extension
client hello, total extension length: 62
=> write handshake message
=> write record
output record: msgtype = 22, version = [3:3], msglen = 117
dumping 'output record sent to network' (122 bytes)
0000: 16 03 03 00 75 01 00 00 71 03 03 88 d9 c4 b1 4f ....u...q......O
0010: 82 ef a2 74 80 5c 6e 3f c4 29 ca a4 8d 61 2b f6 ...t.\n?.)...a+.
0020: 37 ec 93 39 cb 7d d0 39 5a 67 9b 00 00 0a c0 2b 7..9.}.9Zg.....+
0030: c0 31 c0 2d 00 a8 00 ff 01 00 00 3e 00 00 00 16 .1.-.......>....
0040: 00 14 00 00 11 6d 62 65 64 20 54 4c 53 20 53 65 .....mbed TLS Se
0050: 72 76 65 72 20 31 00 0d 00 0a 00 08 04 03 04 01 rver 1..........
0060: 03 03 03 01 00 0a 00 04 00 02 00 17 00 0b 00 02 ................
0070: 01 00 00 16 00 00 00 17 00 00 ..........
=> flush output
message length: 122, out_left: 122
ssl->f_send() returned 122 (-0xffffff86)
<= flush output
<= write record
<= write handshake message
<= write client hello
client state: 2
=> flush output
<= flush output
=> parse server hello
=> read record
=> fetch input
in_left: 0, nb_want: 5
in_left: 0, nb_want: 5
ssl->f_recv(_timeout)() returned 5 (-0xfffffffb)
<= fetch input
dumping 'input record header' (5 bytes)
0000: 15 03 03 00 02 .....
input record: msgtype = 21, version = [3:3], msglen = 2
=> fetch input
in_left: 5, nb_want: 7
in_left: 5, nb_want: 7
ssl->f_recv(_timeout)() returned 2 (-0xfffffffe)
<= fetch input
dumping 'input record from network' (7 bytes)
0000: 15 03 03 00 02 02 28 ......(
got an alert message, type: [2:40]
is a fatal alert message (msg 40)
mbedtls_ssl_handle_message_type() returned -30592 (-0x7780)
mbedtls_ssl_read_record() returned -30592 (-0x7780)
<= handshake
failed
! mbedtls_ssl_handshake returned -0x7780
I am thankfull for every hint in the right direction.
client hello, adding server name extension: mbed TLS Server 1
The client is using the SNI extension to indicate that it wants to talk to mbed TLS Server 1. The server on port 443 of www.google.de can respond as www.google.de, google.de and a bunch of other names that Google controls, but it does know about mbed TLS Server 1, so it sends a fatal alert indicating that it cannot complete the handshake.
You can use the sample client as is to talk to the sample server whose source code should be next to it. To contact another server, you need to change or remove the call to mbedtls_ssl_set_hostname.
I'm using commons-net 3.7 and OpenJDK 11. FTP server is TLSv1.2 implicit.
I can retrieve files but when I try to storeFile it hangs. As I checked the socket.close(); method call at storeFile waits input.
I tried copying InputStream to OutputStream way. Same thing happens when I try to close the OutputStream. It waits and same error occurs.
Why it cannot close socket and end storing file? Thank you.
FTPSClient ftpsClient = new FTPSClient(true);
ftpsClient.connect("host", 990);
ftpsClient.enterLocalPassiveMode();
ftpsClient.setFileType(FTP.BINARY_FILE_TYPE);
ftpsClient.setControlKeepAliveTimeout(300);
ftpsClient.setBufferSize(1024000);
ftpsClient.login("user", "password");
// login is successful, everything seems fine
InputStream inputstream = new FileInputStream("test.pdf");
ftpsClient.storeFile("/upload", inputstream);
// waits 4-5 minutes and gets connection reset
// I can retrieve and delete files, only uploading is problem.
09B0: 62 6A 47 BA 9F F4 9B 74 BE E0 07 0B F5 63 92 C0 bjG....t.....c..
09C0: 2C 26 B6 36 98 3C 83 D4 A4 3F 3C 99 72 6B 24 45 ,&.6.<...?<.rk$E
09D0: FE 9F 3E F4 DA 3B CB B2 18 12 F0 FB 85 ..>..;.......
)
javax.net.ssl|ALL|01|main|2020-09-01 01:31:25.414 CEST|SSLSocketImpl.java:1002|Closing output stream
javax.net.ssl|DEBUG|01|main|2020-09-01 01:31:25.415 CEST|SSLSocketImpl.java:670|close outbound of SSLSocket
javax.net.ssl|DEBUG|01|main|2020-09-01 01:31:25.417 CEST|SSLSocketOutputRecord.java:71|WRITE: TLS12 alert(close_notify), length = 10
javax.net.ssl|DEBUG|01|main|2020-09-01 01:31:25.418 CEST|SSLCipher.java:1727|Plaintext before ENCRYPTION (
0000: 01 00 ..
)
javax.net.ssl|DEBUG|01|main|2020-09-01 01:31:25.418 CEST|SSLSocketOutputRecord.java:85|Raw write (
0000: 15 03 03 00 1A 00 00 00 00 00 00 00 11 1B EB DE ................
0010: 1F A8 2E 8B DE 84 26 1F FD E6 23 C4 81 E7 BC ......&...#....
)
javax.net.ssl|DEBUG|01|main|2020-09-01 01:31:25.418 CEST|SSLSocketImpl.java:473|duplex close of SSLSocket
javax.net.ssl|DEBUG|01|main|2020-09-01 01:31:25.418 CEST|SSLSocketImpl.java:1361|close the underlying socket
javax.net.ssl|DEBUG|01|main|2020-09-01 01:31:25.419 CEST|SSLSocketImpl.java:1380|close the SSL connection (initiative)
javax.net.ssl|DEBUG|01|main|2020-09-01 01:31:25.419 CEST|SSLSocketImpl.java:1408|wait for close_notify or alert
javax.net.ssl|ERROR|01|main|2020-09-01 01:38:14.945 CEST|TransportContext.java:313|Fatal javax.net.ssl|WARNING|01|main|2020-09-01 01:38:14.947 CEST|SSLSocketImpl.java:494|SSLSocket duplex close failed (
"throwable" : {
javax.net.ssl.SSLProtocolException: Connection reset
at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:126)
at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:321)
at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264)
at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:259)
at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:137)
at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152)
at java.base/sun.security.ssl.SSLSocketImpl.waitForClose(SSLSocketImpl.java:1413)
at java.base/sun.security.ssl.SSLSocketImpl.closeSocket(SSLSocketImpl.java:1389)
at java.base/sun.security.ssl.SSLSocketImpl.shutdown(SSLSocketImpl.java:1370)
at java.base/sun.security.ssl.SSLSocketImpl.bruteForceCloseInput(SSLSocketImpl.java:603)
at java.base/sun.security.ssl.SSLSocketImpl.duplexCloseInput(SSLSocketImpl.java:583)
at java.base/sun.security.ssl.SSLSocketImpl.close(SSLSocketImpl.java:484)
at org.apache.commons.net.ftp.FTPClient._storeFile(FTPClient.java:686)
at org.apache.commons.net.ftp.FTPClient.__storeFile(FTPClient.java:645)
at org.apache.commons.net.ftp.FTPClient.storeFile(FTPClient.java:2037)
at my.project.package.util.FTPUtil.main(FTPUtil.java:51)
Caused by: java.net.SocketException: Connection reset
at java.base/java.net.SocketInputStream.read(SocketInputStream.java:186)
at java.base/java.net.SocketInputStream.read(SocketInputStream.java:140)
at java.base/sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:448)
at java.base/sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:165)
at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:108)
... 11 more}
425 Data channel timed out due to not meeting the minimum bandwidth requirement.
SERVER: 425 Data channel timed out due to not meeting the minimum bandwidth requirement.
I have two queue manager servers running on two boxes. QM1 has a sender channel defined , and QM2 has a receiver channel with the same name.
I have created self signed certificate for each QM , extracted and added the public part of each certificate to the other QM's key db. Altered each channel to use CipherSpec TRIPLE_DES_SHA_US.
This setup works perfectly fine, if QM names don't contain any special character. If name of the sender QM is A_QM and the other one is B_QM , the sender channel never comes up and is in RETRYING state.
while creating self-signed certificate I am using label ibmwebspheremqa_qm
in case of A_QM and ibmwebspheremqqm1 when the queue manager is QM1. Similarly when adding the public part of the certificate I am preserving the other QM's label. This is the only difference in the whole setup.
Is there any restriction in defining QM names if I want to configure SSL or TLS ?
I had no trouble creating a pair of QMgrs and channels as described and getting them to run:
[mqm#rhel6base scripts]$ runmqsc A_QM
5724-H72 (C) Copyright IBM Corp. 1994, 2014.
Starting MQSC for queue manager A_QM.
dis chs(*) all
1 : dis chs(*) all
AMQ8417: Display Channel Status details.
CHANNEL(A_QM.B_QM) CHLTYPE(SDR)
BATCHES(0) BATCHSZ(50)
BUFSRCVD(1) BUFSSENT(1)
BYTSRCVD(268) BYTSSENT(268)
CHSTADA(2015-04-01) CHSTATI(10.57.43)
COMPHDR(NONE,NONE) COMPMSG(NONE,NONE)
COMPRATE(0,0) COMPTIME(0,0)
CONNAME(127.0.0.1(3115)) CURLUWID(0C031C5501020010)
CURMSGS(0) CURRENT
CURSEQNO(0) EXITTIME(0,0)
HBINT(300) INDOUBT(NO)
JOBNAME(0000130700000001) LOCLADDR(127.0.0.1(53145))
LONGRTS(999999999) LSTLUWID(0000000000000000)
LSTMSGDA( ) LSTMSGTI( )
LSTSEQNO(0) MCASTAT(RUNNING)
MONCHL(OFF) MSGS(0)
NETTIME(0,0) NPMSPEED(FAST)
RQMNAME(B_QM) SHORTRTS(10)
SSLCERTI(CN=rhel6base.ioptconsulting.com)
SSLKEYDA( ) SSLKEYTI( )
SSLPEER(SERIALNUMBER=55:1C:06:B2,CN=rhel6base.ioptconsulting.com)
SSLRKEYS(0) STATUS(RUNNING)
STOPREQ(NO) SUBSTATE(MQGET)
XBATCHSZ(0,0) XMITQ(B_QM)
XQTIME(0,0) RVERSION(08000001)
RPRODUCT(MQMM)
[mqm#rhel6base ssl]$ runmqakm -cert -list -db key.kdb -stashed
Certificates found
* default, - personal, ! trusted, # secret key
! ibmwebspheremqb_qm
*- ibmwebspheremqa_qm
[mqm#rhel6base ssl]$ runmqakm -cert -list -db ../../B_QM/ssl/key.kdb -stashed
Certificates found
* default, - personal, ! trusted, # secret key
! ibmwebspheremq_a_qm
*- ibmwebspheremqb_qm
[mqm#rhel6base ssl]$
REFRESH SECURITY TYPE(SSL)
The most likely cause for the behavior you are seeing is not issuing refresh security or restarting the QMgrs after updating their keystores. For example:
echo "REFRESH SECURITY TYPE(SSL)" | runmqsc A_QM
echo "REFRESH SECURITY TYPE(SSL)" | runmqsc B_QM
or
endmqm -i A_QM; strmqm A_QM
endmqm -i B_QM; strmqm B_QM
One aspect of security for the keystore is that there is only ever one version of it in memory at a time. If it were possible for one channel to have one version and another channel to have another version, it would become impossible to determine which was the "right" one in order to detect tampering. So when the KDB is updated, the refresh security command causes the QMgr to stop all running TLS channels, dump the KDB from memory, and reload the KDB when one of the channels starts.
(MQ doesn't use SSL, by the way, never has. It uses TLS with SSL ciphers and now that SSL itself is broken, best to get used to saying TLS because that will help to remember to use TLS ciphers exclusively going forward.)
So after updating the KDB if you did not run the refresh, it is likely that the refresh was not done and the QMgr doesn't yet know about the newly added certificate for the remote QMgr.
When SSLCAUTH(OPTIONAL) is not optional
Another common problem with TLS is a misunderstanding of SSLCAUTH(OPTIONAL). Many people believe that this always results in one-way authentication so they set SSLCAUTH(OPTIONAL) and then exchange certs in only one direction. For example, QM1 has TLS channels to QM2 so obviously has its own personal certificate. Then we try to connect A_QM to it. We import A_QM's personal cert to QM1's KDB, refresh security everywhere, DEF CHL(A_QM.QM1) ... SSLCAUTH(OPTIONAL) on both sides and try to start the channel.
The misunderstanding is that if the thing initiating the channel has a personal cert it will send it in all cases. To test with SSLCAUTH(OPTIONAL) requires removing any personal cert from the keystore on the side initiating the connection. Often people do not realize this and spend many hours (in some cases weeks) struggling to understand why this fails.
For your purposes always exchange the personal certs in both directions.
Incomplete cert exchange
The other common problem working with self-signed certs is when a cert is generated multiple times with the same label and/or CN value and there's a mismatch between the personal cert on one end versus the public portion on the other. This is easily checked by viewing the cert details and checking that the fingerprint and other details match like so:
[mqm#rhel6base ssl]$ runmqakm -cert -details -label ibmwebspheremqb_qm -db key.kdb -stashed
Label : ibmwebspheremqb_qm
Key Size : 1024
Version : X509 V3
Serial : 551c06b2
Issuer : CN=rhel6base.ioptconsulting.com
Subject : CN=rhel6base.ioptconsulting.com
Not Before : April 1, 2015 10:54:42 AM EDT
Not After : March 31, 2016 10:54:42 AM EDT
Public Key
30 81 9F 30 0D 06 09 2A 86 48 86 F7 0D 01 01 01
05 00 03 81 8D 00 30 81 89 02 81 81 00 DF 0F 90
8C C2 CA D1 ED 16 E2 A8 DA E3 26 63 45 4B B2 29
37 04 65 A1 D3 30 23 2A 67 AB 61 06 75 E1 8B 87
D2 9A CD 38 4C 63 D6 CC AD 25 55 B3 8B BE 34 4E
32 CB EB FE E2 5D E0 49 2F 57 AC EC 5E 79 A2 52
F6 21 5A 5F 95 AB C4 70 C8 00 68 0B 22 32 8C 1F
4C DB 0C D9 85 B8 06 5A 7C DA 3A 3A BE 12 C8 C1
C0 92 5E FE 09 46 F7 E1 1F 3D 4A AA 63 F0 80 09
3D FE E7 A4 49 5D 86 09 4C B5 0E 1E 97 02 03 01
00 01
Public Key Type : RSA (1.2.840.113549.1.1.1)
Fingerprint : SHA1 :
55 FC 2C 7C 00 8E A7 27 78 0D 99 AD FF 84 58 57
BF 16 1C 62
Fingerprint : MD5 :
90 66 AD 5D 71 AF 75 E8 9A 4A A3 5A DB 15 CD 21
Fingerprint : SHA256 :
7E 43 75 25 31 ED E7 76 FA 40 87 37 F3 B2 9E 6F
2D 55 2D 3C CB 52 60 9C 85 B2 53 F3 1C C0 D2 3C
Extensions
AuthorityKeyIdentifier
keyIdentifier: 8D BC 64 AF D9 12 02 34
authorityIdentifier:
authorityCertSerialNumber:
SubjectKeyIdentifier
keyIdentifier: 8D BC 64 AF D9 12 02 34
Signature Algorithm : SHA1WithRSASignature (1.2.840.113549.1.1.5)
Value
46 D4 8A D9 62 04 CF C4 0E 23 DB 4C F9 AD 25 9B
89 3B FD B9 4F 52 4C DE 36 96 15 92 0E 7B 03 05
E8 85 12 AD E7 40 DB E9 4D 77 8F B7 4B CC 43 1B
AD 6D 13 B1 2F 26 12 C8 1C 17 FE 51 A7 B7 7B EE
80 CA 82 37 98 E1 B4 17 3A B4 CC 20 E7 4E 53 42
C6 E1 C3 1C 54 BD DC 9A 14 86 9A 25 66 AC 11 2C
78 A0 B5 DC 22 FE 52 62 59 27 02 DA 82 07 64 42
38 99 8A A7 52 53 20 C3 B2 FF 8F 6D A6 A3 8F 72
Trust Status : Enabled
[mqm#rhel6base ssl]$ runmqakm -cert -details -label ibmwebspheremqb_qm -db ../../B_QM/ssl/key.kdb -stashed
Label : ibmwebspheremqb_qm
Key Size : 1024
Version : X509 V3
Serial : 551c06b2
Issuer : CN=rhel6base.ioptconsulting.com
Subject : CN=rhel6base.ioptconsulting.com
Not Before : April 1, 2015 10:54:42 AM EDT
Not After : March 31, 2016 10:54:42 AM EDT
Public Key
30 81 9F 30 0D 06 09 2A 86 48 86 F7 0D 01 01 01
05 00 03 81 8D 00 30 81 89 02 81 81 00 DF 0F 90
8C C2 CA D1 ED 16 E2 A8 DA E3 26 63 45 4B B2 29
37 04 65 A1 D3 30 23 2A 67 AB 61 06 75 E1 8B 87
D2 9A CD 38 4C 63 D6 CC AD 25 55 B3 8B BE 34 4E
32 CB EB FE E2 5D E0 49 2F 57 AC EC 5E 79 A2 52
F6 21 5A 5F 95 AB C4 70 C8 00 68 0B 22 32 8C 1F
4C DB 0C D9 85 B8 06 5A 7C DA 3A 3A BE 12 C8 C1
C0 92 5E FE 09 46 F7 E1 1F 3D 4A AA 63 F0 80 09
3D FE E7 A4 49 5D 86 09 4C B5 0E 1E 97 02 03 01
00 01
Public Key Type : RSA (1.2.840.113549.1.1.1)
Fingerprint : SHA1 :
55 FC 2C 7C 00 8E A7 27 78 0D 99 AD FF 84 58 57
BF 16 1C 62
Fingerprint : MD5 :
90 66 AD 5D 71 AF 75 E8 9A 4A A3 5A DB 15 CD 21
Fingerprint : SHA256 :
7E 43 75 25 31 ED E7 76 FA 40 87 37 F3 B2 9E 6F
2D 55 2D 3C CB 52 60 9C 85 B2 53 F3 1C C0 D2 3C
Extensions
AuthorityKeyIdentifier
keyIdentifier: 8D BC 64 AF D9 12 02 34
authorityIdentifier:
authorityCertSerialNumber:
SubjectKeyIdentifier
keyIdentifier: 8D BC 64 AF D9 12 02 34
Signature Algorithm : SHA1WithRSASignature (1.2.840.113549.1.1.5)
Value
46 D4 8A D9 62 04 CF C4 0E 23 DB 4C F9 AD 25 9B
89 3B FD B9 4F 52 4C DE 36 96 15 92 0E 7B 03 05
E8 85 12 AD E7 40 DB E9 4D 77 8F B7 4B CC 43 1B
AD 6D 13 B1 2F 26 12 C8 1C 17 FE 51 A7 B7 7B EE
80 CA 82 37 98 E1 B4 17 3A B4 CC 20 E7 4E 53 42
C6 E1 C3 1C 54 BD DC 9A 14 86 9A 25 66 AC 11 2C
78 A0 B5 DC 22 FE 52 62 59 27 02 DA 82 07 64 42
38 99 8A A7 52 53 20 C3 B2 FF 8F 6D A6 A3 8F 72
Trust Status : Enabled
Debugging
Check the error logs. In particular, it is good security design to give an attacker as little information as possible to always check the logs of the QMgr that is receiving the connection first. If it has detected the error it will have detailed logs and the sending side will have sparse logs like "the remote QMgr disconnected" which doesn't reveal much to an attacker.
If the error is actually on the sending side, then it will have most detailed error messages and the receiving side will have little or none. For example, if the sending side can't find its stash file the connection isn't ever attempted and the receiving side will have no record of the event.
Finally, there is always the possibility that you may discover a bug working with GSKit and MQ, or that you are trying to use features not relevant to version of MQ that you are working on. For this reason, it is always best to include a dspmqver -a in your question. If after all of this, you still can't get it to work, please update the question with the dspmqver -a output and the results of your further testing.
In summary
To sum up:
QMgr names like A_QM are perfectly valid.
First make sure that the QMgrs have picked up their new KDB files after changes by restarting the QMgrs or running REFRESH SECURITY TYPE(SSL).
Make sure to exchange certs in both directions every time.
Check the error logs on both sides starting with the side receiving the connection request.
Always include output from dspmqver -a when requesting help with GSKit, certs or TLS since the behavior varies by version and fix pack.
Original question for reference - see update below
This is an extremely strange problem.
I've got an iBeacon broadcasting from Phone A. Everything I've read seems to say that it's not possible for a phone to continue to broadcast as an iBeacon once it has entered the background. However, I am able to lock my phone, and I continue to see (using LightBlue or a raspberry pi) iBeacon advertising packets emitted, with identical manufacturerData. Indefinitely. Nothing about the packet is altered in any way when the phone enters the background.
Phone B is listening for beacon region enter/exit events, and ranging on enter.
Whenever Phone A is put into the background, Phone B loses it - first the number of beacons being ranged drops to 0, then the region is exited. However, I can inspect the bluetooth packets that continue to be sent across the air and clearly see that they are identical to the ones that were send when the app was in the foreground. Even the transmission rate seems to be about the same.
So my question is this: If Phone B is continuing to receive identical iBeacon-formatted advertising packets from Phone A, how does Phone B decide that it has left the region defined by those packets? None of the actual data sent over the air appears to change, so what is the loss of beacon based on?
Any insight you can give is much appreciated!
Update
Per #davidyoung's suggestion, I used hcidump on the pi to inspect the packets. I also left one of my estimotes on for reference (mac address DA:E3:1D:A7:DE:E8). My device has mac 72:F3:FC:7E:2F:DA Two cases:
Started with the app in the foreground:
pi#raspberrypi ~ $ sudo hcidump --raw & sudo hcitool lescan
[1] 2228
HCI sniffer - Bluetooth packet analyzer ver 2.4
LE Scan ...
device: hci0 snap_len: 1028 filter: 0xffffffff
DA:E3:1D:A7:DE:E8 (unknown)
> 04 3E 2A 02 01 00 01 E8 DE A7 1D E3 DA 1E 02 01 06 1A FF 4C
00 02 15 B9 40 7F 30 F5 F8 46 6E AF F9 25 55 6B 57 FE 6D DE
E8 1D A7 B6 BA
DA:E3:1D:A7:DE:E8 estimote
> 04 3E 25 02 01 04 01 E8 DE A7 1D E3 DA 19 09 09 65 73 74 69
6D 6F 74 65 0E 16 0A 18 E8 DE A7 1D E3 DA B6 E8 DE A7 1D BB
72:F3:FC:7E:2F:DA (unknown)
> 04 3E 2A 02 01 00 01 DA 2F 7E FC F3 72 1E 02 01 1A 1A FF 4C
00 02 15 B9 40 7F 30 F5 F8 46 6E AF F9 25 55 6B 57 FE 6D AE
85 69 C6 B6 A7
72:F3:FC:7E:2F:DA (unknown)
> 04 3E 0C 02 01 04 01 DA 2F 7E FC F3 72 00 A8
Started with the app in the background:
pi#raspberrypi ~ $ sudo hcidump --raw & sudo hcitool lescan
[1] 2234
HCI sniffer - Bluetooth packet analyzer ver 2.4
LE Scan ...
device: hci0 snap_len: 1028 filter: 0xffffffff
DA:E3:1D:A7:DE:E8 (unknown)
> 04 3E 2A 02 01 00 01 E8 DE A7 1D E3 DA 1E 02 01 06 1A FF 4C
00 02 15 B9 40 7F 30 F5 F8 46 6E AF F9 25 55 6B 57 FE 6D DE
E8 1D A7 B6 B5
DA:E3:1D:A7:DE:E8 estimote
> 04 3E 25 02 01 04 01 E8 DE A7 1D E3 DA 19 09 09 65 73 74 69
6D 6F 74 65 0E 16 0A 18 E8 DE A7 1D E3 DA B6 E8 DE A7 1D B6
72:F3:FC:7E:2F:DA (unknown)
> 04 3E 0F 02 01 00 01 DA 2F 7E FC F3 72 03 02 01 1A A6
72:F3:FC:7E:2F:DA (unknown)
> 04 3E 0C 02 01 04 01 DA 2F 7E FC F3 72 00 A6
I don't see any new packets being emitted when I take the app from the background to the foreground (or vice-versa), but I do see a different (much smaller) packet steadily emitted when the app is in the background. This smaller packet is only present when my app is in the background, not on a clean boot of the device.
So it would seem that although the app does continue to emit BTLE packets in the background, they're much smaller and not ibeacon-compliant. This would be consistent with what I've read around the CoreBluetooth "overflow" area when advertising in the background.
I suspect the packets you are seeing in LightBlue and on the Raspberry Pi are not the iBeacon advertisement. It may be that they were coming from a different hardware device or a different app on iOS.
Understand that iOS does allow you to advertise in the background, just not iBeacon advertisements. So if you have another app running that is advertising Bluetooth LE services its advertisements will always get picked up by LightBlue and a Raspberry Pi regardless of whether your app is in the foreground or not.
Since LightBlue does not show you the packet detail, there is no way to tell with this tool if the advertisements are from an iBeacon or not. But you can tell with a Raspberry Pi. Like this:
Start an hcidump in the background showing you raw BLE packets
sudo hcidump --raw &
Start a BLE scan
sudo hcitool lescan
This will give you a unique list of all BLE advertisement packets seen.
Try running this with your app in the background, then bring it to the foreground to see what additional advertisements are seen if any. I suspect you will see one additional advertisement, which is your iBeacon advertisement (look closely for your ProximityUUID), and you will only see it when your app is in the foreground.
My application is using SSL over SMTP.
But I faced a problem of extra byte at the end.
The packet which I recieved is as follows: (Hex dump of SSL Record packet)
17 03 01 01 00 9A 07 74 E3 4B E0 07 17 71 38 BF 29 7E 70
E9 14 CC B1 97 77 4C B9 AB A0 9F 88 7B D4 ED 14 8E 97 F2
5A BE 46 56 D4 12 BC 15 01 49 EE CE A1 ED 3F D3 6E 7F AA
DC 6B DF 41 11 74 7B 55 B8 D3 3E 8D EF 96 52 B0 BD 50 35
09 E7 2A FF 0E 39 58 C7 91 99 95 22 6F B0 73 57 28 B4 EA
C6 28 4C DC 5C DA 6C 31 FB 63 71 7D 08 F0 DD 78 C4 08 C5
27 90 04 C7 09 59 E4 83 F4 4D 9A 7B 65 E9 AF 38 44 B4 CD
9E 4D BE 80 0D 07 24 8D C3 79 99 DC 02 81 D7 97 21 16 0B
28 44 82 ED E4 5F E6 91 81 A5 28 C1 C8 92 60 36 4E DE 27
AF D0 2B EE FB 9D 12 9C 2B 4F 3F 29 F2 04 8F DC 21 39 4F
80 23 7E 78 3C A0 29 E0 67 E7 9F 90 B6 1F D4 08 63 3E CE
73 E1 17 72 8D B1 8C 3D A8 59 C0 0F 03 59 7A A6 5D F9 7A
40 57 D6 8D 94 48 93 BF D8 17 C6 70 79 36 13 D0 F1 D1 D2
69 D4 05 9D 67 86 6D E9 66 D0 83 4A D8 5E 20
The length of this packet as seen from SSL 3.1 protocol is 256 Bytes.
But there is one extra byte at the end (shown in bold at the end).
Due to this extra byte at the end, when next packet is being read, then this 20 is also read and causes error of SSL_R_WRONG_VERSION_NUMBER (I am using OpenSSL Library for SSL).
Next packet which I recieved is like (as per packet sniffer)
17 03 01 00 18 ...
But when next read is being done, OpenSSL reads packet as 20 17 03 01 .. which causes the error (since 17 03 is wrong version for 03 01)
I would like to know if this (extra byte at the end) is a part of SSL standard.
Please suggest me how to handle this case in OpenSSL. OpenSSL version is 1.0.0.
No. The extra byte is not as a part of SSL Standard.
As per SSL Standard (RFC 2246 for TLS 1.0, Latest is RFC 5246 for TLS 1.2) the record of SSL is as below:
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
select (CipherSpec.cipher_type) {
case stream: GenericStreamCipher;
case block: GenericBlockCipher;
} fragment;
} TLSCiphertext;
The fragment will be exactly of the length as specified by uint16 length member. So, the 20 must be getting inserted either incorrectly by the Server Implementation, or some other software in the middle is inserting it when the data is in network.
Openssl reads exactly the number of bytes as specified by uint16 length member which is why it doesn't read 20.
Some of the points which you can focus on are:
1. Does this happen with the first application data packet which is transferred immediately after handshake? (From the content type I assumed this packet dump is for application data)
2. Is this a random occurance? Do all connections with that particular server exhibit the same behavior?
3. You can try to get the dump of the packet sent at the Server to see if 20 is present when the packet is being sent at the Server side itself or it is getting added during it's flight.
4. Could there be a Firewall related problem? (I don't know about Firewall, so didn't give more details here)
Hope this helps!
I was bashing my head with this one today; finally resorted to this:
_sslStream.Write(merged, 0, merged.Length - 1)
Problem solved, move along!