Gatttool stop receiving notification after seconds (Not because of disconnection) - bluetooth

I use gattool to connect with BLE device on Linux virtual machine(Ubuntu). There are three roles in the system: peripheral, central, and laptop(only receiving logging info for debugging)
After connecting, I need to send out a message to the peripheral so that it will send out logging information to Linux when the central interacts with the peripheral. So my code is like this:
connect
# cmd for the peripheral sending out logging
char-write-cmd 0x000f 70
# enable notification
char-write-req 0x000c 0100 --listen
It can print out the notification normally, if the peripheral can keep sending out logging to laptop. But if the peripheral stops sending out the logging for (4-5) seconds, and resumes after that, the laptop will no longer print out the message. But it is not disconnected, because I can still write to the peripheral and receive normal feedback after that. And also no error like (gatttool:5840): GLib-WARNING **: Invalid file descriptor.
What's the possible reason for it and how can to fix it? Thanks!
Sample result:
[02:02:02:02:02:02][LE]> connect
Attempting to connect to 02:02:02:02:02:02
Connection successful
[02:02:02:02:02:02][LE]> char-write-cmd 0x000f 70
listen:02:02:02:02][LE]> char-write-req 0x000c 0100 --l
Characteristic value was written successfully
Notification handle = 0x000b value: 4f 55 54 5f 4e 4f 5f 4d 4f 54 0d 0a
Notification handle = 0x000b value: 43 4d 44 3a 30 31 0d 0a
Notification handle = 0x000b value: 4f 55 54 5f 4e 4f 5f 4d 4f 54 0d 0a
Notification handle = 0x000b value: 43 4d 44 3a 30 31 0d 0a
Notification handle = 0x000b value: 4f 55 54 5f 4e 4f 5f 4d 4f 54 0d 0a
Notification handle = 0x000b value: 43 4d 44 3a 30 30 0d 0a
Notification handle = 0x000b value: 4f 55 54 5f 4e 4f 5f 4d 4f 54 0d 0a
Notification handle = 0x000b value: 43 4d 44 3a 30 31 0d 0a
Notification handle = 0x000b value: 4f 55 54 5f 4e 4f 5f 4d 4f 54 0d 0a
Notification handle = 0x000b value: 43 4d 44 3a 30 30 0d 0a
[02:02:02:02:02:02][LE]> char-write-cmd 0x000f 01
Notification handle = 0x000b value: 4f 55 54 5f 4e 4f 5f 4d 4f 54 0d 0a
Notification handle = 0x000b value: 43 4d 44 3a 30 31 0d 0a
Notification handle = 0x000b value: 4f 55 54 5f 4e 4f 5f 4d 4f 54 0d 0a
Notification handle = 0x000b value: 43 4d 44 3a 30 30 0d 0a
Notification handle = 0x000b value: 4f 55 54 5f 4e 4f 5f 4d 4f 54 0d 0a
Notification handle = 0x000b value: 43 4d 44 3a 30 31 0d 0a
Notification handle = 0x000b value: 31 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 64 00 00
After testing, I think it's more close to "receive the notification and store it, but does not print it out to the terminal until the next command to the gatttool" If I send out some commands to the peripheral, which means the peripheral will also send some commands to the laptop, it will print out the "saved" notifications no matter what next command to gatttool is.
Test result:
[02:02:02:02:02:02][LE]> char-desc
Notification handle = 0x000b value: 4f 55 54 5f 4e 4f 5f 4d 4f 54 0d 0a
Notification handle = 0x000b value: 43 4d 44 3a 30 30 0d 0a
Notification handle = 0x000b value: 4f 55 54 5f 4e 4f 5f 4d 4f 54 0d 0a
Notification handle = 0x000b value: 43 4d 44 3a 30 30 0d 0a
Notification handle = 0x000b value: 4f 55 54 5f 4e 4f 5f 4d 4f 54 0d 0a
Notification handle = 0x000b value: 43 4d 44 3a 30 30 0d 0a
Notification handle = 0x000b value: 4f 55 54 5f 4e 4f 5f 4d 4f 54 0d 0a
Notification handle = 0x000b value: 43 4d 44 3a 30 30 0d 0a
Notification handle = 0x000b value: 4f 55 54 5f 4e 4f 5f 4d 4f 54 0d 0a
Notification handle = 0x000b value: 43 4d 44 3a 30 30 0d 0a
handle: 0x0001, uuid: 00002800-0000-1000-8000-00805f9b34fb
handle: 0x0002, uuid: 00002803-0000-1000-8000-00805f9b34fb
[02:02:02:02:02:02][LE]> char-read-hnd 0x0007
Notification handle = 0x000b value: 4f 55 54 5f 4e 4f 5f 4d 4f 54 0d 0a
Notification handle = 0x000b value: 43 4d 44 3a 30 35 0d 0a
Notification handle = 0x000b value: 50 4f 53 5f 49 4e 53 31 5f 4e 4f 5f 4d 4f 54 0d 0a
Notification handle = 0x000b value: 43 4d 44 3a 30 35 0d 0a
Notification handle = 0x000b value: 50 4f 53 5f 49 4e 53 31 5f 4e 4f 5f 4d 4f 54 0d 0a
Notification handle = 0x000b value: 43 4d 44 3a 30 35 0d 0a
Characteristic value/descriptor: 08 00 10 00 00 00 64 00
The result from btmon. The peripheral sends out the notifications at around 19:36:30, but the timestamp on btmon is 19:37 when I send another cmd on Linux.
> ACL Data RX: Handl.. flags 0x02 dlen 5 #40 [hci0] 2019-10-18 19:36:13.577156
ATT: Write Response (0x13) len 0
< ACL Data TX: Handl.. flags 0x00 dlen 9 #41 [hci0] 2019-10-18 19:37:02.057819
ATT: Write Request (0x12) len 4
Handle: 0x000c
Data: 0100
> ACL Data RX: Hand.. flags 0x02 dlen 19 #42 [hci0] 2019-10-18 19:37:02.154325
ATT: Handle Value Notification (0x1b) len 14
Handle: 0x000b
Data: 4f55545f4e4f5f4d4f540d0a

Related

Hyperledger Fabric: Proposal has not been endorsed

I am trying to commit a transaction on the Blockchain of the Hyperledger Fabric 2.2 after offline signing of the transaction from users private key.
After signing the transaction proposal,I send it to the endorsers for the endorsements and in response i get following endorsements from the endorser peers.
[ { version: 1,
timestamp: null,
response:
{ status: 200,
message: '',
payload:
<Buffer 7b 22 4f 72 67 4e 61 6d 65 22 3a 22 78 79 7a 31 22 2c 22 64 6f 63 54 79 70 65 22 3a 22 63 65 72 74 69 66 69 63 61 74 65 22 2c 22 64 6f 6d 61 69 6e 22 ... > },
payload:
<Buffer 0a 20 ca 1d b7 e3 be aa 49 c8 29 a7 ec 70 22 e8 16 39 42 5a 0f ba e2 d5 3f fd 73 5d 3b 46 fb a0 4b 1f 12 d8 01 0a 64 12 34 0a 0a 5f 6c 69 66 65 63 79 ... >,
endorsement:
{ endorser:
<Buffer 0a 07 4f 72 67 31 4d 53 50 12 d9 07 2d 2d 2d 2d 2d 42 45 47 49 4e 20 43 45 52 54 49 46 49 43 41 54 45 2d 2d 2d 2d 2d 0a 4d 49 49 43 71 54 43 43 41 6c ... >,
signature:
<Buffer 30 45 02 21 00 aa ca ad 65 19 c4 f7 81 14 d2 dc e4 66 78 37 e7 9e 26 da 42 6a a6 d4 9f 6b 82 63 c5 96 36 3d c2 02 20 4e a7 57 ab 6f a7 9f 6c 7b 08 53 ... > },
connection:
{ type: 'Endorser',
name: 'peer0.org1.example.com:7051',
url: 'grpcs://localhost:7051',
options: [Object] },
peer: 'peer0.org1.example.com:7051' },
{ version: 1,
timestamp: null,
response:
{ status: 200,
message: '',
payload:
<Buffer 7b 22 4f 72 67 4e 61 6d 65 22 3a 22 78 79 7a 31 22 2c 22 64 6f 63 54 79 70 65 22 3a 22 63 65 72 74 69 66 69 63 61 74 65 22 2c 22 64 6f 6d 61 69 6e 22 ... > },
payload:
<Buffer 0a 20 ca 1d b7 e3 be aa 49 c8 29 a7 ec 70 22 e8 16 39 42 5a 0f ba e2 d5 3f fd 73 5d 3b 46 fb a0 4b 1f 12 d8 01 0a 64 12 34 0a 0a 5f 6c 69 66 65 63 79 ... >,
endorsement:
{ endorser:
<Buffer 0a 07 4f 72 67 32 4d 53 50 12 d1 07 2d 2d 2d 2d 2d 42 45 47 49 4e 20 43 45 52 54 49 46 49 43 41 54 45 2d 2d 2d 2d 2d 0a 4d 49 49 43 70 54 43 43 41 6b ... >,
signature:
<Buffer 30 44 02 20 6e 9c 3f 83 eb a0 45 5b 94 9b 58 be 38 55 8b 00 58 6c 1e c6 8e 65 bd 34 11 4b 8e 4c 76 6c 76 75 02 20 5c 3f c8 ee 14 43 51 a4 07 e8 3a e7 ... > },
connection:
{ type: 'Endorser',
name: 'peer0.org2.example.com:9051',
url: 'grpcs://localhost:9051',
options: [Object] },
peer: 'peer0.org2.example.com:9051' } ]
But, when i try to build,a required formatted proposal including the endorsements,to send it to the orderer so that orderer network, orders the transaction and sends it to committing peers for commitment on the Blockchain,but it gives following error
Failed to submit transaction: Error: Proposal has not been endorsed
code to build the proposal for the orderer
let commitment = new Commit('pki','mychannel')
let idx = client.newIdentityContext(user.user);
let commit = commitment.build(idx,{endorsement:ProposalResponse})
Followed these instructions https://hyperledger.github.io/fabric-sdk-node/release-2.2/Proposal.html#build
Any thoughts are appreciated

How is socket.io secured natively?

I'm looking at socket.io packets and they are TCP. When I review the value, I see encrypted data. Where and how is socket.io encrypting the messages that pass through the soccket? Is it really secure? This is a VM running with requests over http.
For example, I see
0000 bc ec 23 c3 64 6a 00 15 5d 01 59 06 08 00 45 08 ..#.dj..].Y...E.
0010 00 58 68 cc 40 00 40 06 4e 6c c0 a8 01 05 c0 a8 .Xh.#.#.Nl......
0020 01 0a 00 16 c6 51 15 15 7f 44 69 87 60 58 50 18 .....Q...Di.\XP.`
0030 0b 2e 6c ae 00 00 8b 6f 92 7f b9 1b c2 d6 54 60 ..l....o......T
0040 5e 24 65 2a 0c d6 87 90 fd 87 63 30 9d 69 11 26 ^$e*......c0.i.&
0050 4d 75 8c 7b 5e b2 ad 47 12 9d 05 d0 7c 3b 7c 9e Mu.{^..G....|;|.
0060 b1 0d a0 b7 f1 88 ......

Error in appending to Bytes buffer in for loop and does not concat the entire array [Nodejs]

I am trying to read files in a directory, for each file I am converting it into bytes array and appending everything in combinedBuffer array. Now I want to add all bytes buffer in combinedBuffer to finalBuffer, But I am not able to achieve this, it just iterate over the first bytes buffer in combinedBuffer rather than iterating over the entire combinedBuffer Array.
fileRead = async function(file){
const testFolder = './items/';
var dirFiles = [] // dirFiles Array
fs.readdirSync(testFolder).forEach(file => {
dirFiles.push(file)
})
dirFiles.sort(compareBasedonInt) //Natural Compare is to sort files in sampleFile1, SampleFile2.
var combinedBuffer = []
dirFiles.forEach(function(file){
var eachfileBuffer= fs.readFileSync('./items/'+file) //eachfileBuffer is the bytes buffer which we get after reading the file
combinedBuffer.push(eachfileBuffer)
})
var finalbuffer = Buffer.concat(combinedBuffer)
console.log("final buffer", finalbuffer) // finalBuffer shows just first element of combinedBuffer
console.log("combinedBuffer", combinedBuffer) // shows the array of all the bytes buffer
}
Output
combinedBuffer [ <Buffer 2f 51 40 42 0b 0a 53 0c 4a 25 05 55 7f 06 32 79 0d 50 47 0c 5d 3e 59 0b 51 54 40 5c 4a 5e 53 4f 15 05 4d 1f 41 4e 23 07 1f 52 5f 1f 52 48 14 52 4e 52 ... >,
<Buffer 19 42 01 0d 46 59 4a 58 1a 38 60 06 4a 11 2d 5c 70 65 2e 5a 17 0f 54 14 09 2a 05 14 38 34 47 0f 0e 42 5f 26 56 49 07 19 12 11 5e 4e 01 55 0b 41 26 72 ... >,
<Buffer 17 1a 11 5d 4d 19 1e 44 45 45 57 5f 05 49 19 1a 18 2a 23 27 46 00 47 45 17 45 1c 4f 5b 4f 4b 53 45 55 3e 4b 1d 08 4b 15 1a 1c 18 66 50 1a 4f 55 18 05 ... >,
<Buffer 44 0a 06 50 16 10 58 1b 15 40 07 22 58 0b 51 4e 08 07 46 6f 7c 66 12 57 4e 1d 1b 09 04 4a 40 4f 1e 11 5f 41 41 74 62 5f 76 43 5e 0d 1a 01 1a 0c 7d 44 ... >,
<Buffer 3c 09 5f 5c 6c 15 5c 02 15 5d 00 40 03 09 46 54 49 16 5c 5a ff 9f a2 45 43 00 46 46 65 1b 11 5c 5d 54 29 46 44 07 02 14 45 4b 31 6a 3a 4d 0a 58 18 47 ... >,
<Buffer 6d 4a 19 1b 85 bd ec 0c 0f 0f 4c 4a 41 08 09 1b 4f 0b 0a 1d 41 11 53 4b 1e 41 49 1e ce aa ad 11 22 1d 0f 52 46 1b 7a 0b 0e 15 1e 41 53 02 10 19 4f 01 ... >,
<Buffer 03 58 69 48 04 5f 52 02 08 56 1f 07 76 4e 1d 53 12 5e 5e 58 47 0a 5a 44 77 06 16 5e 03 4a 4d 56 56 01 1f 0b 0c 0c 40 45 0e 0c 4e 08 1b 12 1a 45 4e 50 ... >,
<Buffer 4d 5c 0c 4e 1d c2 a2 f9 1b 11 16 5f 52 00 0c 02 54 40 4d 17 0d 58 4c 1b 24 5b 12 41 4b 47 1a 0a 43 50 7c 6d 34 46 42 5a 43 42 43 38 1b 4b 53 57 5f 43 ... >,
<Buffer 49 4e 1a 13 1c 19 0b 0a 5d 19 41 46 06 14 15 51 15 15 56 57 1c 5d 09 1e 00 41 4a 6f 13 0a 60 60 64 16 4c 01 1e 49 46 0e 50 1d 51 56 5c 09 0e 37 16 12 ... >,
<Buffer 58 1d 4f 5b 4c 33 09 4f 08 19 04 1b 69 7e 2d 5d 22 95 be 8b 14 1b 76 4b 07 21 1f 4f 05 4b 30 2e 02 57 07 00 4d 5f 45 1c 08 39 37 37 41 47 25 09 05 4d ... >,
<Buffer 58 42 43 1f 5e 1e 01 17 54 04 52 1c 1a 04 42 48 52 48 3e 03 05 12 4c 16 5a 49 7e 14 49 53 1a 6f 6f 2f 46 54 54 07 00 7a 23 0a 1c 3b 56 0f 73 0a 00 0b ... >]
finalbuffer <Buffer 2f 51 40 42 0b 0a 53 0c 4a 25 05 55 7f 06 32 79 0d 50 47 0c 5d 3e 59 0b 51 54 40 5c 4a 5e 53 4f 15 05 4d 1f 41 4e 23 07 1f 52 5f 1f 52 48 14 52 4e 52 ... >

Snort rules with content

This will generate an alert:
alert tcp any any <> any any (msg:"Test_A"; sid:3000001; rev:1;)
This will not:
alert tcp any any <> any any (msg:"Test_B"; content:"badurl.com"; http_header; sid:3000002; rev:1;)
I have tried: fast_pattern:only; metadata:service http; nocase; http_header; and others. I cannot get it to work at this generic level. Any ideas why the content attribute does not work? The packet has a URL.
Updated from the comments
0000 9c d2 4b 7d 96 60 3c 15 c2 dc 48 fa 08 00 45 00 ..K}.<. ..H...E.
0010 01 5c ac 2c 40 00 40 06 cf f5 c0 a8 c8 1e 41 fe .\.,#.#. ......A.
0020 f2 b4 dc 41 00 50 d0 e7 97 d0 ae b8 f9 ba 80 18 ...A.P.. ........
0030 ff ff da 1f 00 00 01 01 08 0a 34 03 84 d8 b7 cc ........ ..4.....
0040 3f 04 47 45 54 20 2f 20 48 54 54 50 2f 31 2e 31 ?.GET / HTTP/1.1
0050 0d 0a 48 6f 73 74 3a 20 6d 79 64 6f 6d 61 69 6e ..Host: mydomain
0060 2e 63 6f 6d 0d 0a 55 73 65 72 2d 41 67 65 6e 74 .com..Us er-Agent
The rule that you have provided will never fire with the example packet that you have provided. You have used a content:"POST"; with a http_method modifier but you are attempting to match a packet that is a GET request.
I think that the right content modifier should be http_uri, not http_header. Unless you are trying to capture the Host POST parameter.

BitTorrent protocol can't get answers to my piece requests

I'm developing a BitTorrent client and I'm having trouble getting answers to my piece requests.
To debug, I followed a conversation between uTorrent and transmission using Wireshark and tried to imitate same conversation in my client. But it still doesn't work.
Below is an example conversation happening between my client and transmission. (my client also using -TR--- prefixed peer id, this is only for testing purposes and I'll change this)
Indented messages are coming from transmission, others are messages my client send.
Note that this conversation is not exactly same as how uTorrent and transmission would talk, because my client does not support fast extension yet. (BEP 6)
(Output is taken from Wireshark, lines starting with -- are my comments)
00000000 13 42 69 74 54 6f 72 72 65 6e 74 20 70 72 6f 74 .BitTorr ent prot
00000010 6f 63 6f 6c 00 00 00 00 00 10 00 00 f8 9e 0d fd ocol.... ........
00000020 9c fc a8 52 d9 7a d6 af a4 4d 8f 73 ce 70 b6 36 ...R.z.. .M.s.p.6
00000030 2d 54 52 32 38 34 30 2d 36 68 61 67 76 30 73 70 -TR2840- 6hagv0sp
00000040 34 67 37 6b 4g7k
-- ^ my handshake to transmission
00000000 13 42 69 74 54 6f 72 72 65 6e 74 20 70 72 6f 74 .BitTorr ent prot
00000010 6f 63 6f 6c 00 00 00 00 00 10 00 04 f8 9e 0d fd ocol.... ........
00000020 9c fc a8 52 d9 7a d6 af a4 4d 8f 73 ce 70 b6 36 ...R.z.. .M.s.p.6
00000030 2d 54 52 32 38 34 30 2d 72 73 35 68 71 67 32 68 -TR2840- rs5hqg2h
00000040 6e 70 68 64 nphd
-- ^ transmission answers to my handshake
00000044 00 00 00 1a 14 00 64 31 3a 6d 64 31 31 3a 75 74 ......d1 :md11:ut
00000054 5f 6d 65 74 61 64 61 74 61 69 33 65 65 65 _metadat ai3eee
-- ^ my extended handshake to transmission
00000044 00 00 00 72 14 00 64 31 3a 65 69 31 65 31 3a 6d ...r..d1 :ei1e1:m
00000054 64 31 31 3a 75 74 5f 6d 65 74 61 64 61 74 61 69 d11:ut_m etadatai
00000064 33 65 65 31 33 3a 6d 65 74 61 64 61 74 61 5f 73 3ee13:me tadata_s
00000074 69 7a 65 69 31 34 37 65 31 3a 70 69 35 31 34 31 izei147e 1:pi5141
00000084 33 65 34 3a 72 65 71 71 69 35 31 32 65 31 31 3a 3e4:reqq i512e11:
00000094 75 70 6c 6f 61 64 5f 6f 6e 6c 79 69 31 65 31 3a upload_o nlyi1e1:
000000A4 76 31 37 3a 54 72 61 6e 73 6d 69 73 73 69 6f 6e v17:Tran smission
000000B4 20 32 2e 38 34 65 00 00 00 02 05 80 2.84e.. ....
-- ^ transmission's extended handshake and bitfield
000000C0 00 00 00 01 01 .....
-- ^ transmission unchokes me
00000062 00 00 00 01 02 .....
-- ^ my interested message
00000067 00 00 00 0d 06 00 00 00 00 00 00 00 00 00 00 40 ........ .......#
00000077 00 .
-- ^ piece request
-- no answers ...
00000078 00 00 00 0d 06 00 00 00 00 00 00 00 00 00 00 40 ........ .......#
00000088 00 .
-- ^ piece request again, with 10 seconds interval
-- again no answers...
00000089 00 00 00 0d 06 00 00 00 00 00 00 00 00 00 00 40 ........ .......#
00000099 00 .
-- ^ piece request again, with 10 seconds interval
-- no answers...
Any ideas what am I doing wrong?
Thanks.
EDIT: I updated my client to send unchoke just after sending interested, but I'm still having same problem...
The problem was that I was requesting a piece bigger than the total size of the torrent.
The torrent I was using has 2 files, in total of 12KB. However the piece size of the torrent is 16KB and I was requesting 16KB piece even though the torrent file has only one piece and it's 12 KB in total.
After requesting 12KB instead of 16KB, the problem was solved.

Resources