I would like to echo an array of bytes from the linux terminal to serial port. Have already seen this Sending bytes to serial port from UNIX command line? and from that deduced the command will be something like the following:
printf '%b' '\x9c8684a4624000a0b2668a84400003f00301000000048ab0c0' > /dev/ttyUSB0
To debug the ideia I redirected it to a file with
printf '%b' '\x9c8684a4624000a0b2668a84400003f00301000000048ab0c0' > file.raw
and checked the file with hexedit. But so I've found that ASCII values were been written instead.
In the end I expect the following in the file:
9c 86 84 a4 62 40 00 a0 b2 66 8a 84 40 00 03 f0 03 01 00 00 00 04 8a b0 c0
Related
I want to use my computer as an iBeacon, and I don't succeed (On a Ubuntu 14.04 running in a virtualBox environement on Windows 8.1)
Here is the code I use
#!/bin/bash
sudo hciconfig hci0 up
sudo hciconfig hci0 noleadv
sudo hcitool -i hci0 cmd 0x08 0x0008 1e 02 01 1a 1a ff 4c 00 02 15 e2 c5 6d b5 df fb 48 d2 b0 60 \
d0 f5 a7 10 96 e0 00 00 00 00 c5 00 00 00 00 00 00 00 00 00 00 00 00 00
sudo hciconfig hci0 leadv
My hciconfig result
hci0: Type: BR/EDR Bus: USB
BD Address: 00:C2:C6:18:C5:E9 ACL MTU: 310:10 SCO MTU: 64:8
UP RUNNING PSCAN ISCAN
RX bytes:5333127 acl:66 sco:0 events:887454 errors:0
TX bytes:40617442 acl:64 sco:0 commands:887224 errors:0
I have the bluez version 5.36 installed (checked with bluetoothd -v)
I have seen many Stack overflow post about this but cannot figure it out!
Check Here, Here or Here.
I have bought a real iBeacon to look about what works to help me, here is what I have:
Using hcidump -R I read this
< 01 0B 20 07 01 10 00 10 00 00 00
> 04 0E 04 01 0B 20 00
< 01 0C 20 02 01 01
> 04 0E 04 01 0C 20 00
> 04 3E 2A 02 01 00 01 4F 00 00 02 4D CD 1E 02 01 06 1A FF 4C
00 02 15 E2 C5 6D B5 DF FB 48 D2 B0 60 D0 F5 A7 10 96 E0 00
00 00 00 C5 BB
> 04 3E 2A 02 01 04 01 4F 00 00 02 4D CD 1E 02 0A F4 08 16 F0
FF 64 00 00 00 00 11 09 4D 69 6E 69 42 65 61 63 6F 6E 5F 30
30 30 37 39 BB
> 04 3E 2A 02 01 00 01 4F 00 00 02 4D CD 1E 02 01 06 1A FF 4C
00 02 15 E2 C5 6D B5 DF FB 48 D2 B0 60 D0 F5 A7 10 96 E0 00
00 00 00 C5 BB
> 04 3E 2A 02 01 04 01 4F 00 00 02 4D CD 1E 02 0A F4 08 16 F0
FF 64 00 00 00 00 11 09 4D 69 6E 69 42 65 61 63 6F 6E 5F 30
30 30 37 39 BB
< 01 0C 20 02 00 01
> 04 0E 04 01 0C 20 00
Problem is I don't understand why there so much different paquet size and type (maybe other bluetooth nonBeacon device).
I'm pretty sure that this is the beacon paquet, but theses data make no sense to me
04 3E 2A 02 01 00 01 4F 00 00 02 4D CD 1E 02 01 06 1A FF 4C
00 02 15 E2 C5 6D B5 DF FB 48 D2 B0 60 D0 F5 A7 10 96 E0 00
00 00 00 C5 BB
I have trying to use this to understand it but failed (using some stack overflow responses like the following)
First, in order to get BlueZ to advertise, the byte sequence you supply must include a valid BLE advertisement header, which is a minimum of 8 bytes. So to advertise "helloworld" you actually need to send:
sudo hcitool -i hci0 cmd 0x08 0x0008 10 02 01 1a 0c ff 18 01 48 45 4c 4c 4f 57 4f 52 4c 44
The first 8 bytes are the header and the next 10 bytes are the string "helloworld" encoded as 8-bit ASCII.
The first 8 bytes can be broken down like this:
10 # Total length of the advertising packet
02 # Number of bytes that follow in first AD structure
01 # Flags AD type
1A # Flags value 0x1A = 000011010
bit 0 (OFF) LE Limited Discoverable Mode
bit 1 (ON) LE General Discoverable Mode
bit 2 (OFF) BR/EDR Not Supported
bit 3 (ON) Simultaneous LE and BR/EDR to Same Device Capable (controller)
bit 4 (ON) Simultaneous LE and BR/EDR to Same Device Capable (Host)
0C # Number of bytes that follow in second (and last) AD structure
FF # Manufacturer specific data AD type
18 01 # Company identifier code (0x0118 == Radius Networks)
---------------------
If you got anything that can help me to understand how iBeacon paquet are constructed, thank you
Oh Gosh! I have found someone with exactly the same problem as me.
Look Here.
Response that helped from #Richard Wifall
I saw the same issue as memoryhole where I had to remove the extra zeros. I also had to enable advertising before I configured the advertising data for it to work properly with my dongle.
Here is the exact sequence/commands that worked for me:
sudo hciconfig hci0 up
sudo hciconfig hci0 leadv 3
sudo hcitool -i hci0 cmd 0x08 0x0008 1e 02 01 1a 1a ff 4c 00 02 15 e2 c5 6d b5 df fb 48 d2 b0 60 d0 f5 a7 10 96 e0 00 00 00 00 c5 00
This is what my version of the Radius script ended up looking like:
#!/bin/sh
../ibeacon.conf
echo "Launching virtual iBeacon..."
sudo hciconfig $BLUETOOTH_DEVICE up
sudo hciconfig $BLUETOOTH_DEVICE leadv 3
sudo hcitool -i $BLUETOOTH_DEVICE cmd 0x08 0x0008 1e 02 01 1a 1a ff 4c 00 02 15 $UUID $MAJOR $MINOR $POWER 00
echo "Complete"
This was on a Rasberry Pi with a ORICO BTA-402-BK branded BLE dongle (CSR8510 A10)
(I would have left this as a comment, but didn't have enough rep)
During a fresh installation, I accidentally formatted a disk containing datas. I have tried using some tools: testdisk, foremost, but I did not get good results. (see my unsuccessful post on superuser).
So I have decided to read some docs about ext2 filesystem structure, and I could get some results:
The deleted partition have a directory tree like that:
dev
|-scripts
|-projects
|-services
|-...
Medias
|-downloads
|-Musique
|-...
backup
...
So, based on the ext2 directory entry format:
Directory Entry
Starting_Byte Ending_Byte Size_in_Bytes Field_Description
0 3 4 Inode
4 5 2 Total size of this entry (Including all subfields)
6 6 1 Name Length least-significant 8 bits
7 7 1 Type indicator (only if the feature bit for "directory entries have file type byte" is set, else this is the most-significant 8 bits of the Name Length)
8 8+N-1 N Name characters
I tried to find some datas matching this structure.
I used this script:
var bindexOf = require('buffer-indexof');
var currentOffset=0;
var deviceReadStream = fs.createReadStream("/dev/sdb");
deviceReadStream.on('error',function(err){
console.log(err);
});
deviceReadStream.on('data',function(data){
var dirs = ["dev","scripts","services","projects","Medias","downloads","Musique","backup"];
dirs.forEach(function(dir){
dirOctetFormat = new Buffer(2);
dirOctetFormat.writeUInt8(dir.length,0);
dirOctetFormat.writeUInt8(2,1);// type is directory
dirOctetFormat= Buffer.concat( [dirOctetFormat, new Buffer(dir)]);
var offset = bindexOf( data, dirOctetFormat );
if( offset >= 0 ){
console.log( dir + " entry found at offset " + (currentOffset + offset) );
}
});
currentOffset += data.length;
});
}
I found data which seems to be the directory entry of the dev directory:
===== Current offset: 233590226944 - 217.5478515625Gio ======
scripts entry found at offset 233590227030
services entry found at offset 233590227014
projects entry found at offset 233590228106
If it is the case, I got the inode numbers of its children directories: scripts, projects, services,...
But I do not know what to do with that!
I tried to deduce the location of these inodes, based on this guide,
but as I was unable to find a superblock of the deleted filesystem, I just have to make guesses about the block size, the number of blocks, ...
and that seems a little bit fuzzy to me to hope obtaining a result.
So could you have some intervals for all values needed to obtain the offset of an inode, and a more formal formula to get this offset?
If you have only erased the partition table (or modified it) you can still get your data, if data has not been reused for something else.
ext2 filesystems have a MAGIC number in superblock, so to recover your partition you have only to search for it. I did this on one machine and was able to recover not one, but seven partitions in one disk. You have some chances to get invalid numbers, but just search for that magic. Magic number is defined in include/uapi/linux/magic.h and value is #define EXT2_SUPER_MAGIC 0xEF53 (it's found at offset #define EXT2_SB_MAGIC_OFFSET 0x38 ---from file include/linux/ext2_fs.h)
To search for the superblock, just try to find 0xef53 at offset 0x38 in one sector of the disk, it will mark the first block of the partition. Be careful, that superblock is replicated several times in one partition, so you'll find all the copies of it.
Good luck! (I had when it happened to me)
Edit (To illustrate with an example)
Just see the magic number in one of my own partitions:
# hd /dev/sda3 | head -20
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000400 40 62 08 00 00 87 21 00 26 ad 01 00 f6 30 15 00 |#b....!.&....0..|
00000410 1d 31 08 00 00 00 00 00 02 00 00 00 02 00 00 00 |.1..............|
00000420 00 80 00 00 00 80 00 00 90 1f 00 00 cf 60 af 55 |.............`.U|
00000430 fc 8a af 55 2d 00 ff ff 53 ef 01 00 01 00 00 00 |...U-...S.......|<- HERE!!!
00000440 36 38 9d 55 00 00 00 00 00 00 00 00 01 00 00 00 |68.U............|
00000450 00 00 00 00 0b 00 00 00 00 01 00 00 3c 00 00 00 |............<...|
00000460 46 02 00 00 7b 00 00 00 5a bf 87 15 12 8f 44 3b |F...{...Z.....D;|
00000470 97 e7 f3 74 4d 75 69 12 72 6f 6f 74 00 00 00 00 |...tMui.root....|
00000480 00 00 00 00 00 00 00 00 2f 00 61 72 67 65 74 00 |......../.arget.|
00000490 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000004c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 18 02 |................|
000004d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000004e0 08 00 00 00 00 00 00 00 00 00 00 00 93 54 99 ab |.............T..|
000004f0 aa 64 46 b3 a6 73 94 34 a3 79 46 28 01 01 00 00 |.dF..s.4.yF(....|
00000500 0c 00 00 00 00 00 00 00 e5 61 92 55 0a f3 02 00 |.........a.U....|
00000510 04 00 00 00 00 00 00 00 00 00 00 00 ff 7f 00 00 |................|
00000520 00 80 10 00 ff 7f 00 00 01 00 00 00 ff ff 10 00 |................|
Remember it is on offset 0x38 counted from the block origin, and assume the super block is the second block (block 0 reserved for bootcode, so it will be block 1, with two sectors per block, to make 1k blocksize) in the partition, so you'll have to rewind 0x438 bytes from the beginning of the magic number to get the partition origin.
I have run the command on my whole disk, getting the following result:
# hd /dev/sda | grep " [0-9a-f][0-9a-f] 53 ef" | sed -e 's/^/ /' | head
006f05f0 ee 00 00 11 66 0a 00 00 53 ef 00 00 11 66 2d 00 |....f...S....f-.|
007c21d0 55 2a aa 7d f4 aa 89 55 53 ef a4 91 70 40 c1 00 |U*.}...US...p#..|
20100430 fc 8a af 55 2d 00 ff ff 53 ef 01 00 01 00 00 00 |...U-...S.......|
2289a910 0f 8f 4f 03 00 00 81 fe 53 ef 00 00 0f 84 ce 04 |..O.....S.......|
230d4c70 0a 00 00 00 1c 00 00 00 53 ef 01 00 00 00 00 00 |........S.......|
231b7e50 a0 73 07 00 00 00 00 00 53 ef 0d 00 00 00 00 00 |.s......S.......|
23dbd230 d5 08 ad 2b ee 71 07 8a 53 ef c2 89 d4 bb 09 1f |...+.q..S.......|
25c0c9e0 06 00 00 00 00 4f 59 c0 53 ef 32 c0 0e 00 00 00 |.....OY.S.2.....|
25d72ca0 b0 b4 7b 3d a4 f7 84 3b 53 ef ba 3c 1f 32 b9 3c |..{=...;S..<.2.<|
25f0eab0 f1 fd 02 be 28 59 67 3c 53 ef 9c bd 04 30 72 bd |....(Yg<S....0r.|
Clearly, there are much more uninteresting lines in this listing than the ones we need. To locate the one interesting here, we have to do some computing with the numbers. We have seen that sectors are 512 bytes long (this is 0x200 in hex) and we can have the superblock magic at offset 0x438, so we expect valid offsets to be at 0xXXXXXX[02468ace]38 only. Just select the lines with offsets ending in that expression, and you'll get the first superblock valid (in the third line) at offset 0x20100430.
Substract 0x430 to give the byte offset of the partition (0x20100000, and then, divide the result by 0x200, giving 0x100800, or 1050624)
# fdisk -l /dev/sda | sed -e 's/^/ /'
Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: DF97DAD4-727D-4BB3-BD7B-3C5A584A2747
Device Start End Sectors Size Type
/dev/sda1 2048 526335 524288 256M EFI System
/dev/sda2 526336 1050623 524288 256M BIOS boot
/dev/sda3 1050624 18628607 17577984 8.4G Linux filesystem <-- HERE!!!
/dev/sda4 18628608 77221887 58593280 28G Linux filesystem
/dev/sda5 77221888 85035007 7813120 3.7G Linux filesystem
/dev/sda6 85035008 104566783 19531776 9.3G Linux filesystem
/dev/sda7 104566784 135817215 31250432 14.9G Linux swap
/dev/sda8 135817216 155348991 19531776 9.3G Linux filesystem
/dev/sda9 155348992 1953523711 1798174720 857.4G Linux filesystem
I'm trying to edit a binary file directly and I know two editors, vi and hexedit. But when I open a binary file separately using them, the cotens are different. Below is what I did.
First I use "dd if=/dev/sda of=mbr bs=512 count=1" to generate the binary file, which contains the mbr data. Then I open it using "hexedit mbr", and it displays this:
beginning:
00000000 EB 63 90 D0 BC 00 7C 8E C0 8E D8 BE 00 7C BF 00
00000010 06 B9 00 02 FC F3 A4 50 68 1C 06 CB FB B9 04 00
00000020 BD BE 07 80 7E 00 00 7C 0B 0F 85 0E 01 83 C5 10
ending:
000001E0 FF FF 83 FE FF FF 00 40 D6 02 00 38 2B 01 00 00
000001F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA
I using "vi mbr" open it and type":%!xxd", it displays this:
beginning:
0000000: c3ab 63c2 90c3 90c2 bc00 7cc2 8ec3 80c2
0000010: 8ec3 98c2 be00 7cc2 bf00 06c2 b900 02c3
0000020: bcc3 b3c2 a450 681c 06c3 8bc3 bbc2 b904
ending:
00002b0: bfc3 bf00 40c3 9602 0038 2b01 0000 0000
00002c0: 0000 0000 0000 0000 0000 0000 55c2 aa0a
The hexedit displaying is what I expect in mbr. But what to say with vi displaying? Also the vi displaying seems wrong because there are more than 512 bytes.
Thank you for any explainations!
The command :%!xxd uses the external program xxd, so you should first try to check its output by typing:
xxd mbr
If it looks good, try opening vi in binary mode (no EOL):
vi -b mrb
then :%!xxd
The bytes you see in "vi" seem to be exactly the UTF-8 representation of the binary code.
Maybe "vi" converts the data read in from binary to UTF-8 before passing it to "xxd".
Here is the command I used:
sudo hexdump -C /dev/mem | less
And part of the result it dumped:
00000070 53 ff 00 f0 a4 f0 00 f0 c7 ef 00 f0 e0 ba 00 c0 |S...............|
00000080 ef 27 00 f0 ef 27 00 f0 ef 27 00 f0 ef 27 00 f0 |.'...'...'...'..|
*
00000100 99 1b 32 e7 01 e4 00 f0 65 f0 00 f0 e0 be 00 c0 |..2.....e.......|
00000110 ef 27 00 f0 ef 27 00 f0 ef 27 00 f0 ef 27 00 f0 |.'...'...'...'..|
*
00000180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
The interesting thing is that addresses in [0x00000120, 0x0000017f] are ignored as "*" instead of the value I suppose to see.
As far as I can imagine, those parts are protected from being read, but why? Or am I missing something?
hexdump is suppressing duplicate lines to make the output easier to read.
From the 'man hexdump' page:
-v Cause hexdump to display all input data. Without the -v option,
any number of groups of output lines, which would be identical to
the immediately preceding group of output lines (except for the
input offsets), are replaced with a line comprised of a single
asterisk.
My operating system is Debian Squeeze. Here's the vim version:
VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Jul 12 2010 02:29:33)
I read a tutorial on http://kovisoft.bitbucket.org/tutorial.html and tried to start REPL for MIT-Scheme. Unfortunately, I failed to start.
When I pressed ",c", it started a terminal window loading mit-scheme. Nothing showed in the REPL buffer of vim. Some errors showed in the terminal:
Listening on port: 4005
;netcat: "4005: inverse host lookup failed: Unknown host"
;To continue, call RESTART with an option number:
; (RESTART 1) => Return to read-eval-print level 1.
2 error>
I read the source code and fixed some bugs (about the parameters of netcat and something else), here's the diff file:
*** /home/gaussfrank/slimv/slime/contrib/swank-mit-scheme.scm 2012-02-02 16:41:58.357463955 +0800
--- swank-mit-scheme.scm 2012-02-06 22:30:42.929212874 +0800
***************
*** 113,126 ****
(define (netcat port)
(let* ((sh (os/shell-file-name))
! (cmd (format #f "exec netcat -v -q 0 -l ~a 2>&1" port))
(netcat (start-pipe-subprocess sh
(vector sh "-c" cmd)
scheme-subprocess-environment)))
(list netcat port)))
(define (netcat-accept nc)
! (let* ((rx "^Connection from .+ port .+ accepted$")
(line (read-line (subprocess-input-port nc)))
(match (re-string-match rx line)))
(cond ((not match) (error "netcat:" line))
--- 113,126 ----
(define (netcat port)
(let* ((sh (os/shell-file-name))
! (cmd (format #f "exec netcat -v -q 0 -l -p ~a 2>&1" port))
(netcat (start-pipe-subprocess sh
(vector sh "-c" cmd)
scheme-subprocess-environment)))
(list netcat port)))
(define (netcat-accept nc)
! (let* ((rx "^listening on.*")
(line (read-line (subprocess-input-port nc)))
(match (re-string-match rx line)))
(cond ((not match) (error "netcat:" line))
I retried, but some new problems happened.
;The object #f, passed as the second argument to integer-add, is not the correct type.
;To continue, call RESTART with an option number:
; (RESTART 4) => Specify an argument to use in its place.
; (RESTART 3) => Return to SLIME top-level.
; (RESTART 2) => Close connection.
; (RESTART 1) => Return to read-eval-print level 1.
Here's the log file (swank.log)
[---Sent---] 0.21
(:emacs-rex (swank:connection-info) nil t 1)
[---Sent---] 16.11
(:emacs-rex (swank:swank-require 'swank-fuzzy) nil t 2)
Here's the packet:
8 0.739991 127.0.0.1 127.0.0.1 TCP 50732 > pxc-pin [PSH, ACK] Seq=1 Ack=1 Win=32792 Len=51 TSV=1451459 TSER=1451459
0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ..............E.
0010 00 67 91 53 40 00 40 06 ab 3b 7f 00 00 01 7f 00 .g.S#.#..;......
0020 00 01 c6 2c 0f a5 f9 57 b4 93 fc 40 7f 85 80 18 ...,...W...#....
0030 10 03 fe 5b 00 00 01 01 08 0a 00 16 25 c3 00 16 ...[........%...
0040 25 c3 30 30 30 30 32 64 28 3a 65 6d 61 63 73 2d %.00002d(:emacs-
0050 72 65 78 20 28 73 77 61 6e 6b 3a 63 6f 6e 6e 65 rex (swank:conne
0060 63 74 69 6f 6e 2d 69 6e 66 6f 29 20 6e 69 6c 20 ction-info) nil
0070 74 20 31 29 0a t 1).
9 0.740009 127.0.0.1 127.0.0.1 TCP pxc-pin > 50732 [ACK] Seq=1 Ack=52 Win=32768 Len=0 TSV=1451459 TSER=1451459
0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ..............E.
0010 00 34 5a 46 40 00 40 06 e2 7b 7f 00 00 01 7f 00 .4ZF#.#..{......
0020 00 01 0f a5 c6 2c fc 40 7f 85 f9 57 b4 c6 80 10 .....,.#...W....
0030 10 00 fe 28 00 00 01 01 08 0a 00 16 25 c3 00 16 ...(........%...
0040 25 c3 %.
This is a known problem. I have a patched version of Slimv in my git repo which fixes this issue and quite a few others.
Note that it's quite a while ago that I used Slimv, so I can't recall from the top of my head what the exact changes are I made. I only tested this on OS X, so YMMV.