Trying to write a byte to a 16-bit address on an I2C device (OV5640 camera) using i2cset. I can successfully read from the device registers using the following sequence (read byte from device address 0x3c and register address 0x3030):
i2cset -v -f 1 0x3c 0x30 0x30
i2cget -v -f 1 0x3c
To write to the device, I use this sequence (write byte 0x40 to device address 0x3c and register address 0x3030):
i2cset -v -f 1 0x3c 0x30 0x30
i2cset -v -f 1 0x3c 0x40
This sequence does not show any errors but when the address is read again, the value is unchanged.
Can anyone provide any insight on the correct i2cset syntax to use when writing to this device?
SOLVED! I found the solution for this and it requires using the i2cset block write option (i) as follows:
i2cset -y -f 2 0x3c 0x30 0x30 0x40 i
This command writes the value 0x40 to register address 0x3030 at device address 0x3c.
Related
Attempting to capture traffic but I don't know the write syntax to filter the output to a readable pcap file.
I need to use the syntax
tcpdump -r file.pcap
and to filter eth0 icmp traffic
tcpdump -i eth0 icmp -c 10 > file.pcap
is there a way to do this in one line of command?
Yes, but, if you're writing a pcap file rather than a text file, it doesn't involve the > character.
By default, tcpdump captures traffic from an interface, or reads a capture file, and writes out a human-readable dissection of the packets to the standard output.
You need the -w flag to write out a pcap file, so, in your case, the command is
tcpdump -r file.pcap -w file.pcap ICMP
Your command
tcpdump -i eth0 icmp -c 10 > file.pcap
wouldn't write out a pcap file, it writes out text such as
16:30:59.808885 IP 192.168.1.5 > example.com: ICMP echo request, id 40541, seq 0, length 64
16:30:59.841404 IP example.com > 192.168.1.5: ICMP echo reply, id 40541, seq 0, length 64
If you wanted to write the ICMP traffic to a pcap file, you would do
tcpdump -i eth0 icmp -c 10 -w file.pcap
when sending a request over netcat to a program and listen for the response to that request, netcat only receives the first 8192 bytes and than terminates.
Here are the details:
if something is send using netcat and a pipe
echo "something" | netcat -q 10 -i 3 -w 10 localhost myport
My software generates a response which is definitly larger than 8192 bytes and sends it back to netcat. I verifiyed that all bytes are actually send from my programm back to netcat, so there is no problem.
If the command line version is used:
netcat -q 10 -i 3 -w 10 localhost myport
something
all bytes send from the application are received. I tried various combinations for the -q -i and -w flags to change the amount of received bytes but in the pipe command version it is always 8192.
How can that be fixed?
This is happening because netcat is receiving end-of-file from its standard input. That is, the command echo "something" causes the string something\n to be sent to the pipe connected to netcat's standard input; then the pipe is closed (because the echo command terminated). So, on the first read of the pipe, netcat will receive that string, but on its next read, it will receive EOF. This causes it to break its connection to the peer even though the peer may not be finished sending.
Essentially, after being started as above, netcat will keep sending its standard input to the socket, and the socket to its standard output until one of them is closed. Then it exits.
So you simply need to do something to ensure that netcat doesn't receive EOF on its standard input before it gets EOF on the socket. Something like this will likely do it:
(echo "something" ; sleep 1) | netcat localhost $myport
Now the output of echo "something" is sent to the pipe connected to netcat's input, but the pipe won't actually be closed until the sleep 1 also completes since both commands are started in a sub-shell which is connected to the write end of the pipe. (You might need to tinker with the number of seconds slept if the amount to be sent by the peer is large.)
I am am using Perl open for opening new file on Solaris 10 as follows:
open($fh, ">$filePath");
What is default file character encoding on my system with this call?
The output from locale command is given below
LANG=
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_ALL=
This was not as easy a question to answer as I thought it would be.
The default encoding is raw, which is suitable for binary data. Any character with an ordinal value under 256 is passed as is:
$ perl -e 'print chr(0xFF)' | od -c
00000000 377
00000001
The curious thing is what happens when you try to write a character above ordinal value 255. Then it looks like you get UTF-8 encoding.
$ perl -e 'print chr(0x100)' | od -c
00000000 304 200
00000002
I don't know where or if this behavior is documented.
I am trying to disable the hardware prefetcher to run some memory benchmarks on an Intel core i5 2500. The problem is that there is no option whatsoever in my BIOS to enable or disable the prefetcher. So I am trying to use msr-tools to disable the prefetcher. But msr-tool is failing to write some specific values to the required register (0x1a0h).
$ rdmsr -p 0 0x1a0
850089
$ wrmsr -p 0 0x1a0 0x850289
wrmsr: CPU 0 cannot set MSR 0x000001a0 to 0x0000000000850289
This is the same case for all cpus. But if I try to write the value 0x850088 (simply chosen for testing) it will successfully write that value.
Can anyone point out as to where the problem is and what is the solution for this?
Also I felt weird that there is no prefetcher disabling option in my BIOS. Is this the situation with some version of BIOS?
Thanks.
sudo modprobe msr
sudo rdmsr -p $i 0x1a0 -f 3:0
L2 hardware prefetcher - bit 0
L2 adjacent cache line prefetcher - bit 1
DCU prefetcher - bit 2
DCU IP prefetcher - bit 3
[1]
I get 9 as the response. If the bit is set that prefetcher is OFF.
L2 hardware prefetcher and DCU IP prefetecher are off for me.
To switch them on:
$ sudo rdmsr -p 0 0x1a0
850089
# now we update bits 0 and 3
$ sudo wrmsr -p 0 0x850080 # 0b1001 = 0x9 wheras 0b0000 = 0x0
# check it took
$ sudo rdmsr -p 0 0x1a0
850080
all prefetchers are now on
To switch them off it's similar
$ sudo wrmsr -p0 0x85008f
#this fails for me, I can set bit 1 so L2 adacent cache line prefetcher stays on
$ suod wrmsr -p0 0x85008d
# the others can be switched off
[1] https://software.intel.com/en-us/articles/disclosure-of-hw-prefetcher-control-on-some-intel-processors
If you have a Nehalem, Westmere, Sandy Bridge, Ivy Bridge, Haswell, or Broadwell Intel CPU, you can enable/disable various prefetchers with bits 0:4 of MSR 0x1a4. See: https://software.intel.com/content/www/us/en/develop/articles/disclosure-of-hw-prefetcher-control-on-some-intel-processors.html
# E.g. showing initially all enabled:
rdmsr -a -c 0x1a4
> 0xf
> <etc>
# Disable all 4 prefetchers, by setting all 4 bits:
wrmsr -a 0x1a4 $(( 2**0 | 2**1 | 2**2 | 2**3))
rdmsr -a -c 0x1a4
> 0xf
> <etc>
This gives a performance improvement of about 5% for me, with an application that has a random-access memory intensive workload.
For older Intel Core / NetBurst architectures, it seems to be a different MSR, 0x1a0, with the ability to enable/disable 2 different prefetchers via bits 9 and 19. See:
https://software.intel.com/content/www/us/en/develop/articles/optimizing-application-performance-on-intel-coret-microarchitecture-using-hardware-implemented-prefetchers.html
To disable/enable them you might do something like (untested, cause I don't have a Core CPU - so I get an error if I try set these 2 bits):
MSRORIG=$(printf "0x%x\n" $(rdmsr -c 0x1a0))
# To set bits 9 and 19 and disable the prefetchers:
wrmsr -a 0x1a0 $((MSRORIG | 1<<19 | 1<<9))
# To unset and enable:
wrmsr -a 0x1a0 $((MSRORIG & ~(1<<19 | 1<<9)))
I have a pcap captured with Wireshark. Is there any function in Wireshark that will strip Ethernet layer from the result? Or any command line tool to do it?
I searched a bit more about pcap editors, and I found that this works:
$ bittwiste -I a.pcap -O b.pcap -M 12 -D 1-14
-M 12 sets link type to RAW
-D 1-14 deletes bytes 1-14 in link data layer (Etherenet frame is 14 bytes long)
When I open up result in Wireshark I see "Raw packet data (No link information available)" and IP frame below. So this is what I needed.