I use some SIMCOM GSM module to receive incoming messages. When I send SMS from my mobile phone I see my normal number:
+CMT: "+38012345678", ...
But when SMS comes from my cell operator, or some named SMS service as Google I see somу trash like here from Google:
+CMT: "16p6p6w237562767963656", ...
one more:
+CMT: "w49511#495946535451425", ...
and more:
+CMT: "#497966737471627", ...
According to module documentation this parameter named <oa> and means GSM 03.40 TP-Originating-Address Address-Value string field.
Is it possible to decode it on any programming language, e.g. from python? What can it be? If I switch to UCS2 and decode from it is absolutely the same.
According to SIM800 Series AT Command Manual v1.10, page 114:
GSM 03.40 TP-Destination-Address Address-Value field in string
format; BCD numbers (or GSM default alphabet characters) are converted
to characters of the currently selected TE character set (refer
Command +CSCS in 3GPP TS 27.007); type of address given by
If phone number in CMT message does not start with "+" sign, it is encoded with BCD numbers.
I tried to compare those numbers with ASCII table. This is not exactly BCD encoding, but looks very similar.
To decode "16p6p6w237562767963656" split it into pairs: 16 p6 p6 w2 37 56 27 67 96 36 56
then reverse each pair: 61 6p 6p 2w 73 65 72 76 69 63 65
Now compare to HEX codes in ASCII table and get the result: all services. You may wonder how to read 6p 6p 2w. I wonder either!
After searching other examples of encoded numbers I made an assumption that HEX digits 0, A-F have equivalent of different characters:
0 - w
A
B - #
C - p
D
E - +
F - #
I have no idea, why HEX digits were replaces by random letters.
"w49511#495946535451425" stands for "#Y?KYIVSTAR". The code "11" is unprintable and replaced by "?".
"#497966737471627" stands for "Kyivstar".
Are you sure your module is set to text format (AT+CMGF=1) when receiving those SMS? If you switched off your module and on again it probably is set to "PDU" mode, which is more suited for computers than humans..
See the SIMCOM AT Command manual for details, it's very extensive (380 pages pdf).
Related
I was modifying a piece of PC software I wrote to read multiple NDEF records from an NFC tag. However, one of the tags I have contains a record with what seems to be a mangled NDEF header. It's the last record of 6, the other 5 coming in as expected. I've listed it below. For simplicity, all values are listed in hexidecimal and the payload has been truncated.
Record #6
Header: 42
Type Length: 03
Random Bytes: 00 00 00
Payload Length: 2C (44)
Rec. Type: 6E 2F 70 (n/p)
Payload: **
As you can see, 3 random zero bytes are shoved between what should be the Type Length and Payload Length. I have double checked the Length Field in the TLV and found that it accounts for these 3 bytes. I'm not getting any data truncated off of the end of the TLV due to these added bytes.
I decided to do a sanity check with NXP's TagInfo app to make sure I wasn't just reading the data incorrectly. Checking the data dump from a full scan, I saw that the data does in fact match. I've listed the memory scan below. Only the relevant data points are listed and the payload is, again, truncated.
Memory Dump
addr data
...
[30] -- -- 42 03 |--B.|
[31] 00 00 00 2C |...,|
[32] 6E 2F 70 ** |n/p*|
[33] ** ** ** ** |****|
...
[3D] ** ** ** FE |***.|
...
We thought that maybe this was an issue with padding given that, in this case, the Terminator TLV appears at the end of page 0x3D. However, due to the nature of previous records, this is not always the case. Sometimes, the Terminator TLV shows up in the middle of a page.
However, the strange thing is that, in the same TagInfo app on the NDEF page, it reports the NDEF message as follows.
NDEF Message
...
[A8] 52 03 2C 6E 2F 70 ** ** |R.,n/p**|
[B0] ** ** ** ** ** ** ** ** |********|
...
[D8] ** ** |** |
...
Somehow, the software has not only removed the 3 extra bytes, but has correctly set the SR bit in the NDEF header. I have double checked this with another NFC app on Android and have confirmed that the other app is able to read the NDEF Message this way as well.
My question is, is there a reason or logic behind how the app is able to correct not only the the added bytes, but also the NDEF Header? I'm not sure if this is Android doing the correction or something else deeper in the NDEF message structure. Either way, I'm looking at the right way to make the correction while not effecting how I read the other 5 records held within this tag.
Those bytes are also part of the payload length
If the record does not have the SR (short record) bit set, then the payload length is 4 bytes long rather than one byte.
https://learn.adafruit.com/adafruit-pn532-rfid-nfc/ndef#payload-length-9-9
The first byte is 0x42, which in binary is 0100 0010. If we separate that out, we can see that the record has the ME (or 'Message End') bit set, as well as a TNF ('Type Name Format') of 0x02 - 'MIME Media Record'. The SR bit is bit 4, which is zero in this case.
That's also why they disappear in the version corrected by the TagInfo app - it has set the SR (which is why the header jumps to 0x52) and removed the unnecessary bytes.
If a Solaris based MQ Manager is sending messages to an intermediate Windows MQ Manager that then sends on messages to a Linux MQ manager, does the CCSID need to be changed on them all to be the same? I don't think so but I am being pushed to do so...
I have an issue where a client is sending messages from an application on Solaris via an intermediate MQ Manager on Windows but the Linux MQ Manager final destination based application receives the message with CR/LF line ending characters it can't deal with. Should the receiver end group write a conversion exit program? Or an MCA?
IBM MQ does not deal with line feeds. It is not like transferring a file with ftp and using ascii mode where ftp will convert from Unix LF end of line to Window CR and LF end of line. For MQ it is just another character in the character set to translate. If the sending app is sending data that includes CR/LF characters, MQ will treat them as any other character in the data. If the receiving application expecting a file with end of lines to be sent as a MQ message it would be required to deal with the end of lines.
MQ Classes for Java applications running on a Solaris server default to CCSID 819, and a IBM MQ queue manager running on Solaris also will default to CCSID 819. CCSID 819 is described as ISO 8859-1 ASCII.
I created a file called test.txt containing the single word "test" and ran unix2dos against the file.
The output below shows the ASCII characters as HEX values:
$cat test.txt | hexdump -C
00000000 74 65 73 74 0d 0a |test..|
00000006
Note that in the above output the ASCII hex values 0d is the CR and 0a is the LF, these are the common Windows end of line.
If we assume that the default CCSID 819 is used for both the Solaris MQ Classes for Java application and the Solaris queue manager, then we can start out with the assumption that the above two hex values represent CR/LF at the end of each line.
You stated that your Windows queue manager has CCSID 437 which is typical for a US based Windows server. CCSID 437 is described as USA PC-DATA and is also ASCII.
Linux queue managers typically default to CCSID 1208. CCSID 1208 is described as UTF-8 with IBM PUA and is a Variable Byte character set it can have from 1 to four bytes per character. This can represent over a million characters including all ASCII characters. All 127 ASCII characters are represented in UTF-8 as the same single byte HEX values as in ASCII.
Going from ASCII to UTF-8 is loss less, going from UTF-8 to ASCII can have loss if non-ASCII characters are used since there is not a equivalent character in ASCII and MQ converts it to the default substitution character with HEX value 1A. I have seen this for example with a Euro symbol. Most if not all of the first 255 characters of UTF-8 are the same as CCSID 819.
Given the above CCSID assumptions the conversion would look like this:
Original IBM MQ Classes for Java app running on Solaris sending data with CR/LF end of line characters:
$cat test.txt | hexdump -C
00000000 74 65 73 74 0d 0a |test..|
00000006
Solaris Queue Manager Sender channel with CONVERT(YES) sending to Windows Queue Manager with CCSID 437:
cat test.txt | iconv -f IBM819 -t IBM437 | hexdump -C
00000000 74 65 73 74 0d 0a |test..|
00000006
As expected the output is the same since both 819 and 437 are ASCII character sets and the data was not representing any thing above the first 127 ASCII characters.
Solaris Queue Manager Sender channel with CONVERT(YES) sending to Windows Queue Manager with CCSID 437 Sender channel with CONVERT(YES) sending to Linux Queue Manager with CCSID 1208:
cat test.txt | iconv -f IBM819 -t IBM437 | iconv -f IBM437 -t UTF-8 | hexdump -C
00000000 74 65 73 74 0d 0a |test..|
00000006
As expected the output is the same since both 819 and 437 are ASCII character sets and the first 127 characters of UTF-8 (1208) are normal ASCII characters.
Summary: If the sending application is sending CR/LF in the data, MQ message conversion will not change this and if the CCSIDs in use are the above listed CCSIDs it does not even change the actual HEX character value. The sending application would need to change what they are sending or the receiving application would need to accommodate these characters.
A good reference on ASCII, UNICODE, UTF-8 and more can be found in the article "Unicode, UTF8 & Character Sets: The Ultimate Guide".
I smell a bad setup in your MQ environment and anyone who says to make them all the same doesn't know or doesn't understand MQ (& should have zero opinion about the configuration).
Also, setting the sender channel CONVERT attribute to YES is a VERY bad idea and ONLY should be used in extreme cases. see IBM Best Practices for more information. The ONLY time data conversion should be done is when the application issues an MQGET with Convert.
Since, Solaris has no clue about CR/LF, I going to guess at what is going wrong:
The message's Format field of MQMD has the value 'MQSTR' set.
The sender channel between the Solaris queue manager has the attribute CONVERT set to YES
The receiving application on Linux did NOT issue and MQGET with Convert.
Questions:
Did the Solaris application actually put the message with CR/lF?
Did the Solaris application set the MQMD Format field to 'MQSTR'?
Why are the messages hoping through the Windows queue manager? Why not make a direct connection between Solaris queue manager and the Linux queue manager?
What value does the CONVERT attribute of the Solaris sender channel have? i.e. Is it Yes or No?
The simplest solution is to have the Linux application issue an MQGET with Convert assuming the MQMD Format field is set to 'MQSTR'. MQ will automatically convert the message data to the correct platform.
If the MQMD Formet field is not set to 'MQSTR' then MQ will NOT convert the message data between platforms. That would imply that the Solaris application put the CR/LF in the message. I find this hard to believe. If a developer did this then they truly do not know MQ (and should not be programming it).
I am trying to read and write data on Mifare DESFire cards using ISO 7816-4 APDU commands. I followed the steps:
Select application using {00,A4,04,00,07,D2,76,00,00,85,01,00}.
I get the response as 9100.
Then I select file using {00,A4,00,00,02,3F,00} and I get the response as 9100.
Then I try to read the file using command {00,B0,00,00,03} and I get an error with code 6A86.
Now I want to know the exact commands to read and write the data on the cards. I think I still don't get the meaning of P1 and P2 in read/write commands. I already tried many other combinations but I always get errors like 6A86, 6982, etc.
I assume you receive the status word 9000 on success. If you actually receive 9100 when using ISO/IEC 7816-4 basic inter-industry command APDUs something very strange must be going on. 91xx status words should only be returned when you use the ISO/IEC 7816-4 wrapped command set (i.e. when the class byte of the command APDU is set to 0x90).
Let's look at what you currently do:
You start my selecting the MIFARE DESFire ISO AID D2760000850100:
00 A4 0400 07 D2760000850100
This makes sure that the card is in ISO/IEC 7816-4 framing mode and automatically selects the MF (master file; i.e. the PICC level application).
You then, again(!), select the MF (PICC level application):
00 A4 0000 02 3F00
So you are now at the same level as after step 4.
Finally, you try to read 3 bytes starting at offset 0 from the currently selected file using the READ BINARY APDU:
00 B0 0000 03
Since the currently selected file is the MF you can't read binary data from it. The MF does not have a data part. Consequently, the card reports the error code 6A86 ("wrong parameter P1 and/or P2") as it tries to tell you that reading at offset 0 (P1|P2 = 0x0000) from the MF (currently selected file indicated by the upper bit of P1 being zero) makes no sense.
Therefore, before you can read binary data, you need to select an elementary file (EF), probably even located in a different application (dedicated file, DF), that contains an actual data part. This can be done bei either explicitly sending SELECT commands for EF (and, if necessary, the DF) or by implicitly selecting the EF using a short file identifier in P1 of the first read binary command. In the latter case, you would set the upper bit of P1 to one to indicate that the remaining part of P1 encodes a short file ID. In both cases you would need to know the file/application identifiers of the files and applications that you want to read from.
I posted this to the net-snmp mailing list Monday and got no reply, so I am trying here.
I am confused and I hope someone can help.
I am writing an SNMP agent for a Cortex M4 application.
The SNMP books I have bought and what I have read on the net indicate that all data fields should be ASN.1 encoded. I know the OIDs are ASN.1 encoded. I am not sure if that applies to other fields like Request ID.
Looking at snmp commands sent by net-snmp, it appears that the Request ID field is a simple (4 byte) 32 bit integer.
Here is a screen shot showing an snmpget transaction monitored through Wireshark:
http://www.ko4bb.com/net-snmp/RequestID.png
It shows the RequestID to be 1750020546 (decimal) and 0x684F31C2 in hex. The data field in Wireshark also shows it to be “68 4f 31 c2”
This is not ASN.1 encoded, otherwise the first 3 bytes would have their bit 7 set to 1 and the last byte would have bit 7 set to 0, meaning the first 3 values would be >0x7F and the last value should be < 0x80
So is ASN.1 not used for the RequestID field?
I added the wireshark tag, as this is purely a Wireshark issue.
The Request ID field, is strictly in ASN.1 BER format, which is 02 04 68 4f 31 c2.
You should be careful that Wireshark is too smart to parse the data and hide some details from you.
Please check the botton panel where 68 4f 31 c2 is highlighted. Wireshark highlights them, but intentionally ignore 02 04 ahead. That's the problem.
As #GuyHarris pointed out in the comment, this Wireshark behavior is configurable. Other packet analyzers (such as Microsoft Network Monitor) might behave differently in the same scenario.
I am working with SMS Concatenation. My GSM Modem supports PDU Mode. My UDH works fine when i use the IEI for 05 for using a certain port but then i tried using IEI 00 which is for concatenation. I am receiving the two messages combined as single message without problem but i am receiving unreadable sms of weird characters. Below is my PDU for the first part.
0041000B819062972624F60000A0050003A1020154741914AFA7C76B9058FEBEBB41E6371EA4AEB7E173D0DB5E983E8E832881DD6E741E4F7D905A2A2CBA0783D3D5E83C4F2F7DD0D32BFF12075BD0D9F83DEF6B21C44479741ECB03E0F22BFCF2E10155D06C5EBE9F11A2496BFEF6E90F98D07A9EB6DF81CF4B697E5203ABA0C6287F57910F97D7681A8E832285E4F8FD720B1FC7D7783CC6F
and this one is for the second part:
0041000B819062972624F600007B050003A102027890BADE86CF416F7B590EA2A3CB2076589F0791DF6717888A2E83E2F5F4780D12CBDF7737C8FCC683D4F5367C0E7ADBCB72101D5D06B1C3FA3C88FC3EBB4054741914AFA7C76B9058FEBEBB41E6371EA4AEB7E173D0DB5E9683E8E832881DD6E741E4F7D905
Thanks a lot for helps in advance.
Did you remember to pad your UDH with additional bits so that your UD septets that follow start on a septet boundary?
If for example you have 6 octets in your UDH (most common), which equals 48 bits, then you have to add 1 more bit so that the GSM-7 encoded characters start on a septet boundary (49 bits is 7 septets).
Read http://mobiletidings.com/2009/02/18/combining-sms-messages/ for more information.