windows 7, msvs2010, C++ CLI
I want to save last 50 chars into a file from data received from serial port. Normally, to receive all data I would do this:
//Reading all exsisting data in serialport buffer
String^ data = _serialPort->ReadExisting();
sw->Write(data);
delete (IDisposable^)sw;
What should I do if I want to save only last, say, 50 char?
Related
I want to do mass erase on my msp430f2619 using bsl. I use software jump in my code to invoke bsl. I send 0x80, get 0x90 from BSL(ack). Then i send mass erase command and get 0x90 again. Then i power off my device, then i power on the device, then i send 0x80 and get 0x90, that means there was no mass erase operation.
Read command is not working too. I send password (0xFF 32 times), after that send rx command, then i get few coorect bytes, and then infinite raw of 0xff.
I think i miised something before jump to bsl, please give an example code, or step by step instruction on how to make software jump to bsl and make it work correctly.
If you are sending 0x80 only, then get back 0x90, this confirms you have entered into the BSL since this completes the required synchronization sequence (see section 2.1 of this document). You should not require the "RX password" command since the "Mass erase" command is not protected.
The next sequence after the synchronization is to send the desired command, which should be the "Mass erase". There is a format to each of the BSL commands called the data frame. You want to send the following data frame: eight mandatory bytes (note two dummy bytes), and two checksum bytes. Note the "Mass erase" command does not contain data bytes, but you need to calculate the checksum bytes. Here are the bytes to be sent to perform the mass erase:
80 18 04 04 dd dd 06 A5 CL CH
Where: dd = dummy bytes (any value accepted), CL = Checksum low, CH = Checksum high
After sending this data frame then you should receive the ACK (0x90) byte. Then power off the device.
I am reading data from 3, 12bit ADCs and streaming the data constantly to computer by USB (UART) . Each package of the data stream is as follows:
It has 6 bytes of data from 3 ADCS which the 8 bits LSB of each ADC is in one byte and the rest 4 bits MSB is in another byte. Also there are 2 bytes with "z" and "y" character at the end of the package of data to realize the start and end of each package. How do I unpack this data with LabVIEW?
Here is the answer for unpacking the data:
When first connecting to a new SSH host in Putty it displays a message asking me to verify the RSA fingerprint:
When viewing this same information on the network (e.g. through Wireshark), the same value is not shown, instead is shown as:
How can I calculate the fingerprint from the information shown in the Packet Capture?
The value shown in wireshark is the full public key from the server. The fingerprint (MD5 Hash value) of this value is shown to the user in putty as it's much easier (shorter) to read that expecting the user to match up the entire key.
To calculate the public key fingerprint it is necessary to first convert the hex stream given by Wireshark to the the byte stream equivilent then to calculate the MD5 hash from this and output in hexadecimal format.
A crude implementation of this in python is below which will take the wireshark value (HEX DH host Key copied as a HEX Stream) on STDIN and output the fingerprint on STDOUT:
import md5
import sys
# Accepts a wireshark encoded string on STDIN an outputs MD5 fingerprint to STDOUT
# The value copied from the 'HEX DH host Key' as a HEX Stream
wireshark_key = sys.stdin.readline()
# Change the HEX value into the raw byte stream, which will include non-printable characters
hex_string = wireshark_key.strip().decode("hex")
# Calculate the MD5 Hash of the byte stream and output in Hexidecimal format
md5_fingerprint = md5.new(hex_string).hexdigest()
# Tidy up the output so it matches what Putty displays
putty_fingerprint = ":".join([md5_fingerprint[i:i+2] for i in range(0, len(md5_fingerprint), 2)])
print(putty_fingerprint)
To run this, save the wireshark value (public key) to a file and then execute:
cat <key.txt> | python scriptname.py
The output should then match what is displayed by Putty on first connect as well as in the Event Log.
The following web pages were very useful in figured this all out:
http://passionateaboutis.blogspot.co.uk/2015/07/ssh-fingerprint-from-pcap.html
https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Public_Key_Authentication
Whilst this script may be useful for one off cases, if you need to obtain fingerprints for a large number of hosts, nmap and one of it's NSE scripts may be more efficient:
https://nmap.org/nsedoc/scripts/ssh-hostkey.html
Saving the output from NMAP to XML will automatically store the calculated fingerprint for all hsots.
I've search high and low looking for a way to display all text from FTP.exe to a richtextbox. so far i've only been able to do is display the output code. the idea is to run the test and display and capture to a file which hasn't been a problem except i can't seem to display all text as you would see it in Command.Hoping to see all text when done. Please Help!!
Here is he code:
Private Sub Rectangle1_Click(sender As Object, e As EventArgs) Handles Rectangle1.Click
Dim p As New Process()
With p
.StartInfo.Arguments = " -s:c:\dsl\ftptest\speed1.txt 65.40.220.20"
.StartInfo.CreateNoWindow = True
.StartInfo.FileName = "ftp"
.StartInfo.RedirectStandardError = True
.StartInfo.RedirectStandardOutput = True
.StartInfo.UseShellExecute = False
.Start()
Dim StErr As StreamReader = .StandardError
Dim StOut As StreamReader = .StandardOutput
While (Not StOut.EndOfStream)
Me.RichTextBox1.AppendText(String.Format("{0}", StOut.ReadLine() & vbCrLf))
End While
.WaitForExit()
End With
End Sub
End Class
Here is the output from the code:
User (65.40.220.20:(none)): Hash mark printing On ftp: (2048 bytes/hash mark) .
hash
get test.1meg
#
cd upload
put test.1meg
#
close
bye
Here is What I'm looking for:
C:\DSL\FTPTEST>call FTP -s:c:\dsl\FTPtest\speed1.txt 65.40.220.20
Connected to 65.40.220.20.
220-
This server is provided as a EMBARQ Speedtest server for DSL customers only.
Any other use is prohibited.
You may login using anonymous ftp and download the test files to determine your speed.
You may upload the same files to the upload directory to test your upload speed.
You may only upload the files that you previously downloaded from this server.
You cannot download anything from the upload directory.
Remember, some ftp programs measure speed in bytes per second.
DSL speeds are measured in bits per second. There are 8 bits in a byte.
If you can download at 64 kilobytes per second then that is the same as
512 kilobits per second.
220 65.40.220.20 FTP server ready
User (65.40.220.20:(none)):
331 Anonymous login ok, send your complete email address as your password.
230-
This server is provided as a EMBARQ Speedtest server for DSL customers only.
Any other use is prohibited.
You may login using anonymous ftp and download the test files to determine your speed.
You may upload the same files to the upload directory to test your upload speed.
You may only upload the files that you previously downloaded from this server.
You cannot download anything from the upload directory.
Remember, some ftp programs measure speed in bytes per second.
DSL speeds are measured in bits per second. There are 8 bits in a byte.
If you can download at 64 kilobytes per second then that is the same as
512 kilobits per second.
230 Anonymous access granted, restrictions apply.
ftp> hash
Hash mark printing On ftp: (2048 bytes/hash mark) .
ftp> get test.1meg
200 PORT command successful
150 Opening ASCII mode data connection for test.1meg (1048576 bytes)
#
#
#
ftp: 1048576 bytes received in 5.96Seconds 175.94Kbytes/sec.
ftp>
ftp> cd upload
250 CWD command successful
ftp> put test.1meg
200 PORT command successful
150 Opening ASCII mode data connection for test.1meg
#
#
#
226 Transfer complete.
ftp: 1048576 bytes sent in 5.98Seconds 175.23Kbytes/sec.
ftp>
ftp>
I think that you might be able to redirect the output of your command to a file. e.g, at the end of the command add (assuming that you have a directory c:\temp)
your command here > c:\temp\TestOutput.text
Then in your program, add a file system watcher to watch that file and load it into the textbox when it changes. If you're doing this lots of time then you might have to dynamically generate a filename and delete the files when no-longer needed.
I have a very simple piece of code which just writes a small amount of data to a file at some regular interval. Once my program has created the file and appended some data, when I open this file in vim(or any other editor for that matter) and edit it, my process cannot seem to update the file anymore. I do not see any errors being returned from the syscall. I tried tracing the system calls, and did not observe anything weird even while the file is NOT being updated.
Since each process gets its own file table entry which has the current offset, all I was expecting was an output file with data interspersed with writes from the two non-cooperating processes(possibly garbled too). But what I am observing is that my program cannot update the file anymore once any other editor writes to the file.
Couple of other interesting observations
1) When I cat something to the output file, my program can continue to update no problem
2) When multiple instances of my own program are writing to the same file, everything is fine again
I understand that there's mandatory locking to prevent multiple writes, but I am trying to understand whats happening underneath. Also this kind of scenario behaves normally for some loggers (like system log, apache logs etc)
Any ideas to explain this behavior?. Also any hints on how I can debug this further?
My code is pretty simple:
1 int main(int argc, char** argv)
2 {
3 const char* buf;
4 if(argc < 2)
5 buf = "test->";
6 else
7 buf = argv[1];
8
9 int fd;
10 if((fd = open("test.log", O_CREAT|O_WRONLY|O_APPEND, 0644)) == -1) {
11 perror("Cannot open test.log");
12 exit(1);
13 }
14
15 int num_bytes = strlen(buf), num_bytes_written = -1;
16
17 while(1) {
18 if((num_bytes_written = write(fd, buf, num_bytes)) == -1) {
19 perror("Could not write to fd");
20 }
21 fsync(fd);
22 sleep(5);
23 }
24 }
When the vim(1) editor exits, it's likely replacing the original file with the edited version. Your process is holding the original file open but that file no longer exists in the sense that it's directory entry has been replaced and, so, no process that doesn't already have the file open can access it. Your process is now appending to a file that can't be accessed by any other process. Once your process closes the file, it will be gone for good (unless you run a partition recovery program).
Your vim editor works on a cached version of your file. It modifies this cache while your other programs append to the original file. When you save with vim, you overwrite the original file with the updated cached file and loose all logs.