I have a piece of software running on concurrent DOS 3.1, which I emulate with QEMU 5.1.
In this program, there are several options to print data. The problem is that the data arriving to my host does not correspond to the data sent.
the command to start qemu:
qemu-system-i386 -chardev file,id=imp0,path=/path/to/file -parallel chardev:imp0 -hda DISK.Raw
So the output sent on parallel port of my guest is redirected to /path/to/file.
When I send the charactère 'é' from CDOS:
echo é>>PRN
The code page used on CDOS is Code Page 437, and in this charactere set, the charactère é is represented by 0x82, but on my host, instead, I receive the following:
cp437 é -> 0x82 ---------> host -> x1b52 x017b x1b52 x00
So I tried something else. I wrote the charactère 'é' in a file, and sent the file with nc.exe (from brutman and libmtcp), and with nc, the value stays 0x82.
So my question, what happen when I send my data to virtual parallel port? When does my data get transformed? Is it the parallel port on Concurrent DOS? Is it the QEMU? I can't figure out how to send my data through LPT1 properly.
I also tried this:
qemu-system-i386 -chardev socket,id=imp0,host=127.0.0.1,port=2222,server,nowait -parallel chardev:imp0 -hda DISK.Raw
I can read the socket fine, but same output as when I write in a file, the é get transformed to x1b52 x017b x1b52 x00.
The byte sequence "1B 52 01 7B 1B 52 00" is using Epson FX-style printer escape sequences (there's a reference here). Specifically, "1B 52 nn" is ESC R n which selects the international character set, where character set 0 is USA and 1 is France. So the sequence as a whole is "Select French character set; print byte 0x7b; select US character set". In the French character set for this printer standard, 0x7B is the e-acute é.
This is almost certainly the CDOS printer driver assuming that the thing on the end of PRN: is an Epson printer and emitting the appropriate escape sequences to output your text on that kind of printer.
OK, so i finally figured it out... After hours of searching where this printer.sys driver could be, or how to remove it, no Concurrent DOS, the setup command is "n". And of course, it is not listed in the "help" command...
Anyway, in there you can setup your printer, and select "no conversion" for the port you want. And it was actually on Epson MX-80/MX-100.
So thanks to Peter's answer, you led me to the right path !
Related
I have started working with the NXP NTAG 424 TT chip together with nfcpy and an Identive SCL3711 Reader/Writer. I can successfully send and receive APDU commands, securely authenticate myself and send and receive commands in encrypted communication mode.
However I can't read or write Data to the chip, and I don't know why. Here is what I do (mostly taken from the NXP application note Page 24):
I send the command "ISO Select NDEF application using DF Name"
00A404C07D276000085010100
Then I perform the secure authentication protocol via AuthenticatEV2First with key 0x00
I try to write some data as follows:
cmd_header = 02000000040000
cmd_data = 00D1FF00 (before padding)
cmd_data = 00D1FF00800000000000000000000000 (after padding)
The complete command which I send looks like this:
cla cmd P1&2| Lc |ISO Header | encrypted Data |LE
90 8D 00 00 1F 02 000000 040000 6688A4D75482FC972C2447A1A20F0AC9C073C1CF506B2BD3 00
However the chip only responds with 917E: "Length Error"" which translates to "Command size not allowed"
What am I doing wrong? It can't be the encryption, I tested that with various other commands (getTTStatus, SetConfiguration) and these all worked fine. I quadruple checked the header. Did I perhaps fail to select the correct File, or did I miss some other steps? Also what does "Command size not allowed" mean? This error is pretty cryptic to me (which is funny when working with encrypted chips :D).
Any help is greatly appreciated!
Best regards,
Phil
The length of "encrypted data" field in your case is 24 bytes, whereas the length which you have mentioned in ISO Header is "040000" i.e. 4 bytes.
Your encrypted data length should match with the length of data you are writing.
In your case there is mismatch in both lengths and resulting in error.
Hope the information is clear.
Cheers!
I'm using STM32 discovery board to communicate to a device that takes ASCII commands.
I use HAL_UART_TRANSMIT_IT to send data, that works fine.
I want to send ASCII command XM3 to the device. When I use virtual port programs as realterm, I just click on ascii and put the baudrate, databitc etc etc and when I type in XM3 and click on +CR it send the command and it works fine, if CR is not included it doesent work.
When I try to do that from my MCU I use this code and it does not work, any ideas how to send ASCII commands in C via serial port?
char txD[3]="XM3";
__HAL_UART_ENABLE_IT(&huart1, UART_IT_TC);
HAL_UART_Transmit_IT(&huart1, (uint8_t *)txD ,3);
When I send this to realterm it shows XM3 but when I send this to the device nothing happens.
I need to know how I send XM3 and a CR to the device.
If you send the command via Realterm and check the +CR option, Realterm does append a Carriage Return, i.e. ASCII Code 13.
In order to reproduce this behavior in your code, you should define the command as follows:
char txD[4]="XM3\r";
Respectively, if the receiver also expects to receive a Newline, i.e. ASCII Code 10, you should define it as follows:
char txD[5]="XM3\r\n";
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'm trying to send non-printable ASCII characters (codes 128 - 255) through telnet to a Ruby app using Socket objects to read data in.
When I try to send \x80 through telnet, I expect Ruby to receive a string of 3 bytes: 128 13 10.
I actually receive a string of 6 bytes: 92 120 56 48 13 10.
Do I need to change something about how telnet is sending the information, or how the Ruby socket is accepting it? I've read through all the telnet jargon I can comprehend. A point in the right direction would be very much appreciated.
92 120 56 48 13 10
is in decimal ASCII:
\ x 8 0 \r \n
So you are doing something very wrong and it's not the Telnet. The escape sequence \x80 was treated literally instead of being understood as single character of code=128.
I guess you have used '\x80' instead of "\x80". Note the different quotes. If that was a single character, you can in Ruby also use ? character to denote a character: ?\x80 so for example:
"\x80\r\n" == ?\x80 + ?\r + ?\n
=> true
while of course
'\x80\r\n' == "\x80\r\n"
=> false
--
To summarize long story from the comments:
originally data to be sent was entered manually through telnet terminal
telnet terminals often don't accept any escape codes and "just send" everything they got directly, sometimes copying&pasting a text with special characters work, sometimes terminals provide some extra UI goodies to send special characters - but this time the terminal was very basic and pasting it didn't work, and there was no UI goodies
instead of entering the data manually, sending a file through a pipe to the telnet terminal seemed to work much better. Some data arrived, but not good
piping the data to nc(netcat) instead of telnet terminal almost seemed to work, binary data arrived, but it was not perfect yet
after examining the input file (the one that was piped to nc) with hexdump utility, it turned out that the file contained not exactly what we thought, it seems that the editor used to create the file saved the text with wrong encoding, and it has added some extra unwanted bytes
finally, a utility called xxd helped to produce a good binary data from a tailored hex-text; output of xxd could be directly piped to nc (netcat)
I need to send data to a hardware device over serial port. I'm using a program called serial port tool for os x.
After I connect to the device there is a form box where I can type data to send. I have no idea how to format the data.
Here is an excerpt from the manual for the device.
"The Net Manager Command structure consists of one start byte, one command byte, five bytes of data, and a one byte checksum. Each message packet is formatted as follows:"
an example command is:
Byte0=30 Byte1=7 Byte2=5 Byte3=1 Byte4=2 Byte5=0 Byte6=245
How do I type that into the form box in serial port tool?
Thanks,
Seth
Does the "serial port tool" you're using come with any documentation?
Assuming the "form box" is expecting printable characters, what you're looking for is a way to input an arbitrary byte value. For example, there might be a mechanism that lets you use an octal or hexadecimal escape sequence (such as \036 or \24).