I'm trying to implement a modbus asynchronous serial server with the library Pymodbus. I'm using a ModbusRtuFramer as a frame template. Unfortunately, when I send a command, it looks like the bytes are splitted and the frame is not recognized. I post both the code and the log.
StartSerialServer(context, identity=identity,
framer=ModbusRtuFramer,
port='/dev/ttyS2',
timeout=0.1,
baudrate=9600,
bytesize=8,
parity='N',
stopbits=1)
I send the command 03102c0002 (read 2 holding registers starting from address 102c. The log says:
DEBUG:pymodbus.server.asynchronous:Data Received: 0x1
DEBUG:pymodbus.framer.rtu_framer:Frame - [b'\x01'] not ready
DEBUG:pymodbus.server.asynchronous:Data Received: 0x3 0x10 0x2c
DEBUG:pymodbus.framer.rtu_framer:Frame check failed, ignoring!!
DEBUG:pymodbus.framer.rtu_framer:Resetting frame - Current Frame in buffer - 0x1 0x3 0x10 0x2c
DEBUG:pymodbus.server.asynchronous:Data Received: 0x0 0x2 0x1 0x2
DEBUG:pymodbus.framer.rtu_framer:Frame check failed, ignoring!!
DEBUG:pymodbus.framer.rtu_framer:Resetting frame - Current Frame in buffer - 0x0 0x2 0x1 0x2
DEBUG:pymodbus.server.asynchronous:Data Received: 0x1
DEBUG:pymodbus.framer.rtu_framer:Frame - [b'\x01'] not ready
DEBUG:pymodbus.server.asynchronous:Data Received: 0x3 0x10 0x2c
DEBUG:pymodbus.framer.rtu_framer:Frame check failed, ignoring!!
DEBUG:pymodbus.framer.rtu_framer:Resetting frame - Current Frame in buffer - 0x1 0x3 0x10 0x2c
DEBUG:pymodbus.server.asynchronous:Data Received: 0x0 0x2 0x1
DEBUG:pymodbus.framer.rtu_framer:Frame check failed, ignoring!!
DEBUG:pymodbus.framer.rtu_framer:Resetting frame - Current Frame in buffer - 0x0 0x2 0x1
DEBUG:pymodbus.server.asynchronous:Data Received: 0x2
DEBUG:pymodbus.framer.rtu_framer:Frame - [b'\x02'] not ready
DEBUG:pymodbus.server.asynchronous:Data Received: 0x1
DEBUG:pymodbus.framer.rtu_framer:Frame check failed, ignoring!!
DEBUG:pymodbus.framer.rtu_framer:Resetting frame - Current Frame in buffer - 0x2 0x1
DEBUG:pymodbus.server.asynchronous:Data Received: 0x3 0x10 0x2c 0x0
DEBUG:pymodbus.framer.rtu_framer:Frame check failed, ignoring!!
DEBUG:pymodbus.framer.rtu_framer:Resetting frame - Current Frame in buffer - 0x3 0x10 0x2c 0x0
DEBUG:pymodbus.server.asynchronous:Data Received: 0x2 0x1 0x2
DEBUG:pymodbus.framer.rtu_framer:Frame check failed, ignoring!!
DEBUG:pymodbus.framer.rtu_framer:Resetting frame - Current Frame in buffer - 0x2 0x1 0x2
DEBUG:pymodbus.server.asynchronous:Data Received: 0x1
DEBUG:pymodbus.framer.rtu_framer:Frame - [b'\x01'] not ready
DEBUG:pymodbus.server.asynchronous:Data Received: 0x3 0x10 0x2c
DEBUG:pymodbus.framer.rtu_framer:Frame check failed, ignoring!!
DEBUG:pymodbus.framer.rtu_framer:Resetting frame - Current Frame in buffer - 0x1 0x3 0x10 0x2c
DEBUG:pymodbus.server.asynchronous:Data Received: 0x0 0x2 0x1 0x2
DEBUG:pymodbus.framer.rtu_framer:Frame check failed, ignoring!!
DEBUG:pymodbus.framer.rtu_framer:Resetting frame - Current Frame in buffer - 0x0 0x2 0x1 0x2
Related
I'm trying to use an Arduino to create a single-button Bluetooth keyboard and struggling to construct a valid HID descriptor. I've been able to send key events to my iOS device using the default generic desktop keyboard HID descriptor, but once I try using the following HID descriptor I'm unable to trigger a home button event (AC Home: 0x0223) when I send HID reports to toggle bit 0 from 0 → 1 → 0:
0x05, 0x0c, // USAGE_PAGE (Consumer Devices)
0x09, 0x01, // USAGE (Consumer Control)
0xa1, 0x01, // COLLECTION (Application)
0x15, 0x00, // LOGICAL_MINIMUM (0)
0x25, 0x01, // LOGICAL_MAXIMUM (1)
0x75, 0x01, // REPORT_SIZE (1)
0x95, 0x01, // REPORT_COUNT (1)
0x0c, 0x02, 0x23 // USAGE (AC Home)
0x81, 0x06, // INPUT (Data,Var,Rel)
0x95, 0x07, // REPORT_COUNT (7 bytes of padding)
0x81, 0x03, // INPUT (Cnst,Var,Abs)
0xc0 // END_COLLECTION
Am I missing something in the construction of my HID descriptor? Is AC Home not the correct usage ID for the home button in iOS?
Any help would be greatly appreciated!
Yes there is a small error in your descriptor:
0x0c, 0x02, 0x23 // USAGE (AC Home)
should be:
0x0a, 0x23, 0x02 // USAGE (AC Home)
Your current descriptor decodes as:
//--------------------------------------------------------------------------------
// Decoded Application Collection
//--------------------------------------------------------------------------------
/*
05 0C (GLOBAL) USAGE_PAGE 0x000C Consumer Device Page
09 01 (LOCAL) USAGE 0x000C0001 Consumer Control (Application Collection)
A1 01 (MAIN) COLLECTION 0x01 Application (Usage=0x000C0001: Page=Consumer Device Page, Usage=Consumer Control, Type=Application Collection)
15 00 (GLOBAL) LOGICAL_MINIMUM 0x00 (0) <-- Info: Consider replacing 15 00 with 14
25 01 (GLOBAL) LOGICAL_MAXIMUM 0x01 (1)
75 01 (GLOBAL) REPORT_SIZE 0x01 (1) Number of bits per field
95 01 (GLOBAL) REPORT_COUNT 0x01 (1) Number of fields
0C (ERROR) <-- Error: Item (0C) is not a MAIN, GLOBAL or LOCAL item
02 2381 (MAIN) <-- Error: Item (02) is not a MAIN item. Expected INPUT(8x) OUTPUT(9x) FEATURE(Bx) COLLECTION(Ax) or END_COLLECTION(Cx) (where x = 0,1,2,3).
06 9507 (GLOBAL) USAGE_PAGE 0x0795 Reserved
81 03 (MAIN) INPUT 0x00000003 (1 field x 1 bit) 1=Constant 1=Variable 0=Absolute 0=NoWrap 0=Linear 0=PrefState 0=NoNull 0=NonVolatile 0=Bitmap
C0 (MAIN) END_COLLECTION Application
*/
//--------------------------------------------------------------------------------
// Reserved inputReport (Device --> Host)
//--------------------------------------------------------------------------------
typedef struct
{
// No REPORT ID byte
// Collection: CA:ConsumerControl
uint8_t : 1; // Pad
} inputReport_t;
After the above change is implemented it looks in better shape:
//--------------------------------------------------------------------------------
// Decoded Application Collection
//--------------------------------------------------------------------------------
/*
05 0C (GLOBAL) USAGE_PAGE 0x000C Consumer Device Page
09 01 (LOCAL) USAGE 0x000C0001 Consumer Control (Application Collection)
A1 01 (MAIN) COLLECTION 0x01 Application (Usage=0x000C0001: Page=Consumer Device Page, Usage=Consumer Control, Type=Application Collection)
15 00 (GLOBAL) LOGICAL_MINIMUM 0x00 (0) <-- Info: Consider replacing 15 00 with 14
25 01 (GLOBAL) LOGICAL_MAXIMUM 0x01 (1)
75 01 (GLOBAL) REPORT_SIZE 0x01 (1) Number of bits per field
95 01 (GLOBAL) REPORT_COUNT 0x01 (1) Number of fields
0A 2302 (LOCAL) USAGE 0x000C0223 AC Home (Selector)
81 06 (MAIN) INPUT 0x00000006 (1 field x 1 bit) 0=Data 1=Variable 1=Relative 0=NoWrap 0=Linear 0=PrefState 0=NoNull 0=NonVolatile 0=Bitmap
95 07 (GLOBAL) REPORT_COUNT 0x07 (7) Number of fields
81 03 (MAIN) INPUT 0x00000003 (7 fields x 1 bit) 1=Constant 1=Variable 0=Absolute 0=NoWrap 0=Linear 0=PrefState 0=NoNull 0=NonVolatile 0=Bitmap
C0 (MAIN) END_COLLECTION Application
*/
//--------------------------------------------------------------------------------
// Consumer Device Page inputReport (Device --> Host)
//--------------------------------------------------------------------------------
typedef struct
{
// No REPORT ID byte
// Collection: CA:ConsumerControl
uint8_t CD_ConsumerControlAcHome : 1; // Usage 0x000C0223: AC Home, Value = 0 to 1
uint8_t : 1; // Pad
uint8_t : 1; // Pad
uint8_t : 1; // Pad
uint8_t : 1; // Pad
uint8_t : 1; // Pad
uint8_t : 1; // Pad
uint8_t : 1; // Pad
} inputReport_t;
...the HID descriptor was decoded with hidrdd (freeware) from github or sourceforge
I'm debugging the memory dump of a process, of which I assume the number of handles becoming too large. When I open the dump in Windbg, I see following error/warning message (I don't know if this is relevant to my question) :
Dir entry 8, HandleDataStream stream has too many elements (0xfefffd > 0x400000)
While launching the Windbg !handle extension command, I see following error message:
0:000> !handle
ERROR: !handle: extension exception 0x80004002.
"Unable to read handle information"
I have already launched that same extension command on other memory dumps of the same process (maybe another version). Hence I don't understand the relevance of most Google results of that error code (something about a wrong interface).
Does anybody know what might cause the mentioned error code and what I can do in order to see the amount of handles in my application dump?
For your information, I'm not interested in every single handle, just the total amount of them.
Edit after first comments
The results of .dumpdebug are the following: (only handle related)
0:000> .dumpdebug
----- User Mini Dump Analysis
MINIDUMP_HEADER:
Version A793 (62F0)
NumberOfStreams 13
Flags 61826
0002 MiniDumpWithFullMemory
0004 MiniDumpWithHandleData
...
Stream 8: type HandleDataStream (12), size 27D7FF98, RVA 101DEF6C
Dir entry 8, HandleDataStream stream has too many elements (0xfefffd > 0x400000)
Stream 9: type CommentStreamW (11), size 000001A0, RVA 000102E0
'
*** "C:\Internal\Tools\Procdump\procdump.exe" -ma -accepteula 18732 C:\Dumps\Own_Application_PID_18732_2019_02_07_11_38_02_777_NOW.dmp
*** Manual dump'
(The results of .dumpdebug and Dumpchk.exe are very similar, I decided not to add them too)
Edited after chdump.py result
Hereby the result (partially) of chdump.py:
MINIDUMP_HEADER EXCLUDING SIGNATURE
version 0xa793
internal version 0x62f0
Number of Streams 0xd
Stream Directory RVA 0x20
CheckSum 0x0
u.TimeDateStamp 2019-02-07 11:45:24
Flags 0x61826
MINIDUMP_DIRECTORY
StreamType DataSize RVA
0x3 0x754 0x434
0x11 0x9cc 0xb88
0x4 0x1588 0x1554
0x13 0x290 0x2adc
0x9 0x12250 0x37fc9f84
0x10 0x6b080 0x37f5ef04
0x7 0x38 0xbc
0xf 0x340 0xf4
0xc 0x27d7ff98 0x101def6c
0xb 0x1a0 0x102e0
0x0 0x0 0x0
0x0 0x0 0x0
0x0 0x0 0x0
_MHDesc2
Handle TypeNameRva ObjectNameRva Attributes GrantedAccess HandleCount PointerCount ObjectInfoRva Reserved0
0x4 0x10490 0x104a8 0x10 0x3 0x7c 0x1ee0c0b 0x0 0x0
0x8 0x104c2 0x0 0x0 0x100020 0x2 0x80001 0x0 0x0
0xc 0x104d0 0x104dc 0x0 0x1 0x2 0x80001 0x0 0x0
0x10 0x1055e 0x1056a 0x0 0x20019 0x2 0x80000 0x0 0x0
0x14 0x105f6 0x0 0x0 0x1f0000 0x2 0x80002 0x0 0x0
0x18 0x1060e 0x0 0x0 0x1f0003 0x2 0x80001 0x0 0x0
0x28 0x1061e 0x1062a 0x0 0xf003f 0x2 0x7ffba 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x30 0x10652 0x0 0x0 0x1f0003 0x2 0x40002 0x0 0x0
0x34 0x10662 0x0 0x0 0x1f0003 0x2 0x40002 0x0 0x0
0x38 0x10672 0x0 0x0 0x1f0003 0x2 0x40002 0x0 0x0
0x3c 0x10682 0x0 0x0 0x1f0003 0x2 0x40002 0x0 0x0
0x40 0x10692 0x0 0x0 0x1f0003 0x2 0x40002 0x0 0x0
0x44 0x106a2 0x0 0x0 0x1f0003 0x2 0x40002 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x4c 0x106b2 0x106ca 0x10 0xf 0x44 0xfe9d9c 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x78 0x106f2 0x0 0x0 0x1f0003 0x2 0x7ffc7 0x0 0x0
0x7c 0x10702 0x1070e 0x0 0x20019 0x2 0x7fffe 0x0 0x0
0x80 0x1077a 0x0 0x0 0x100020 0x2 0x40002 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x88 0x10788 0x0 0x0 0x100003 0x2 0x40002 0x0 0x0
0x8c 0x107a0 0x0 0x0 0x100003 0x2 0x40002 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0xb0 0x107b8 0x0 0x0 0x1f0003 0x2 0x40002 0x0 0x0
0xb4 0x107c8 0x0 0x0 0x1f0003 0x2 0x40002 0x0 0x0
0xb8 0x107d8 0x0 0x0 0x1f0003 0x2 0x7fddf 0x0 0x0
0xbc 0x107f0 0x0 0x0 0x1f0003 0x2 0x7fea0 0x0 0x0
0xc0 0x10808 0x0 0x0 0x1f0003 0x2 0x40002 0x0 0x0
0xc4 0x10820 0x0 0x0 0x1f0003 0x2 0x40002 0x0 0x0
0xc8 0x10838 0x0 0x0 0x1f0003 0x2 0x7fff6 0x0 0x0
0xcc 0x10850 0x0 0x0 0x1f0003 0x2 0x7fd62 0x0 0x0
0xd0 0x10868 0x0 0x0 0x1f0003 0x2 0x6f1cc 0x0 0x0
0xd4 0x10878 0x0 0x0 0x1f0003 0x2 0x40002 0x0 0x0
0xd8 0x10888 0x0 0x0 0x1f0003 0x2 0x40002 0x0 0x0
0xdc 0x108a0 0x108ac 0x0 0xf003f 0x2 0x80000 0x0 0x0
0xe0 0x108f6 0x10902 0x0 0x20019 0x2 0x80000 0x0 0x0
0xe4 0x10958 0x10964 0x0 0x20019 0x2 0x80001 0x0 0x0
0xe8 0x10a08 0x0 0x0 0x1f0003 0x2 0x40002 0x0 0x0
0xec 0x10a18 0x0 0x0 0x1f0003 0x2 0x40002 0x0 0x0
0xf0 0x10a28 0x0 0x0 0x1f0003 0x2 0x40002 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x100 0x10a38 0x0 0x0 0x1f0003 0x2 0x40002 0x0 0x0
0x104 0x10a48 0x0 0x0 0x1fffff 0x4 0xff501 0x10a5a 0x0
0x108 0x10a96 0x0 0x0 0x1f0000 0x2 0x7fff8 0x0 0x0
0x10c 0x10aae 0x0 0x0 0x1f0003 0x2 0x7fffe 0x0 0x0
0x110 0x10abe 0x0 0x0 0x1f0003 0x2 0x5ebe2 0x0 0x0
0x114 0x10adc 0x0 0x0 0xf00ff 0x2 0x73b3f 0x0 0x0
0x118 0x10b00 0x0 0x0 0x100002 0x2 0x80002 0x0 0x0
0x11c 0x10b10 0x0 0x0 0x1 0x2 0x80002 0x0 0x0
0x120 0x10b3e 0x0 0x0 0x100002 0x2 0x7d72d 0x0 0x0
0x124 0x10b4e 0x0 0x0 0x1 0x2 0x5ebe2 0x0 0x0
0x128 0x10b7c 0x0 0x0 0x1f0003 0x2 0x80000 0x0 0x0
0x12c 0x10b8c 0x0 0x0 0x1f0003 0x2 0x80000 0x0 0x0
0x130 0x10b9c 0x0 0x0 0x1f0003 0x2 0x5671f 0x0 0x0
0x134 0x10bac 0x0 0x0 0x1f0003 0x2 0x40002 0x0 0x0
0x138 0x10bbc 0x0 0x0 0x1fffff 0x4 0xbf505 0x10bce 0x0
0x13c 0x10c0a 0x0 0x0 0x1f0003 0x2 0x40002 0x0 0x0
0x140 0x10c1a 0x0 0x0 0x1f0003 0x2 0x74432 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x148 0x10c2a 0x0 0x0 0x1f0003 0x2 0x80001 0x0 0x0
0x14c 0x10c3a 0x0 0x0 0x100001 0x2 0x7feb3 0x0 0x0
0x150 0x10c48 0x0 0x0 0x1f0003 0x2 0x80001 0x0 0x0
0x154 0x10c58 0x0 0x0 0x1f0000 0x2 0x4d899 0x0 0x0
0x158 0x10c70 0x0 0x0 0x1f0003 0x2 0x7ffdc 0x0 0x0
0x15c 0x10c80 0x0 0x0 0x1f0003 0x2 0x80000 0x0 0x0
0x160 0x10c90 0x10c9c 0x0 0xf003f 0x2 0x7ffd6 0x0 0x0
0x164 0x10ce6 0x0 0x0 0x1f0003 0x2 0x80000 0x0 0x0
0x168 0x10cf6 0x10d0a 0x0 0x4 0xa3 0x28c0002 0x0 0x0
0x16c 0x10d5a 0x10d66 0x0 0xf003f 0x2 0x7ffc4 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x174 0x10db0 0x10dc0 0x10 0x100001 0x53 0x18003f 0x0 0x0
0x178 0x10e10 0x10e1c 0x0 0x20019 0x2 0x7fff4 0x0 0x0
0x17c 0x10e94 0x10ea0 0x0 0x20019 0x2 0x7fff4 0x0 0x0
0x180 0x10f1c 0x10f30 0x0 0x4 0xa3 0x28c0002 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
0x188 0x10f80 0x0 0x0 0x120089 0x2 0x7fffc 0x0 0x0
0x18c 0x10f8e 0x0 0x0 0xf0005 0x2 0x80001 0x0 0x0
It does very far: the Python script even stopped, due to a memory error, after having generated ±13 million(!) lines of results.
Thanks in advance
The Format of Minidump file is almost Documented You can parse the file yourself without having to Rely on windbg
say with python
the Error seems to be Explicit there is some corruption in the _MINIDUMP_DIRECTORY->DataSize
The Max Number of Handles iirc is limited to 10000 handles per process
(browse for Raymond Chens blog old new thing)
so there is must be some hardcoded limit for the stream size which when violated
results in that error
below is a quickly churned python script that takes a dump and dumps the raw data
open the dump in hexeditor and peer around or maybe patch to recover part handle information
%%writefile chkdump.py
import sys
import os
import struct
import datetime
scriptname = os.path.split(sys.argv[0])[1]
if (len(sys.argv) != 2 ):
sys.exit("usage python %s path_to_dump" % scriptname)
fin = open(sys.argv[1],'rb')
if( fin.read(4) != 'MDMP' ):
fin.close()
sys.exit("not a windbg dump file no MDMP signature")
print ( "MINIDUMP_HEADER EXCLUDING SIGNATURE")
dmphdr = struct.unpack("<HHiiiiQ",fin.read(28))
print ( "%-20s\t0x%x") % ( "version", dmphdr[0] )
print ( "%-20s\t0x%x") % ( "internal version", dmphdr[1] )
print ( "%-20s\t0x%x") % ( "Number of Streams", dmphdr[2] )
print ( "%-20s\t0x%x") % ( "Stream Directory RVA", dmphdr[3] )
print ( "%-20s\t0x%x") % ( "CheckSum", dmphdr[4] )
print ( "%-20s\t") % ( "u.TimeDateStamp" ),
print ( datetime.datetime.fromtimestamp(dmphdr[5]))
print ( "%-20s\t0x%x") % ( "Flags", dmphdr[6] )
print ("\nMINIDUMP_DIRECTORY ")
print ("%-24s%-24s%-24s") % ("StreamType" , "DataSize","RVA")
streamdata = []
for i in range(0,dmphdr[2],1):
streamdata.insert(i,struct.unpack("<iii",fin.read(12)))
print ("%-24s%-24s%-24s") % ( hex(streamdata[i][0]),
hex(streamdata[i][1]),hex(streamdata[i][2]))
HStreamLoc, = [z for (x,y,z) in streamdata if x == 0xc]
HStreamDSize, = [y for (x,y,z) in streamdata if x == 0xc]
fin.seek(HStreamLoc)
sizeof_HDStream = 16
HDStream = struct.unpack("<iiii",fin.read(sizeof_HDStream))
assert (HDStream[1] * HDStream[2] + sizeof_HDStream ) == HStreamDSize
print ("_MHDesc2")
sizeof_MHDesc2 = 40
HDesc = []
print ("%-14s%-14s%-14s%-14s%-14s%-14s%-14s%-14s%-14s") % ("Handle" ,"TypeNameRva",
"ObjectNameRva","Attributes","GrantedAccess","HandleCount","PointerCount",
"ObjectInfoRva","Reserved0")
for i in range(0,HDStream[2],1):
HDesc.insert(i,struct.unpack("<Qiiiiiiii",fin.read(sizeof_MHDesc2)))
print ("%-14s%-14s%-14s%-14s%-14s%-14s%-14s%-14s%-14s") % ( hex(HDesc[i][0]),
hex(HDesc[i][1]), hex(HDesc[i][2]), hex(HDesc[i][3]),hex(HDesc[i][4]),
hex(HDesc[i][5]), hex(HDesc[i][6]),hex(HDesc[i][7]), hex(HDesc[i][8]))
when executed it would return data like this for handle stream
MINIDUMP_HEADER EXCLUDING SIGNATURE
version 0xa793
internal version 0x61b1
Number of Streams 0xd
Stream Directory RVA 0x20
CheckSum 0x0
u.TimeDateStamp 2019-02-14 02:38:24
Flags 0x61826
MINIDUMP_DIRECTORY
StreamType DataSize RVA
0x3 0x94 0x1dc
0x11 0xcc 0x270
0x4 0xc40 0x33c
0x13 0x388 0xf7c
0x9 0x1100 0x91f0
0x10 0x4f30 0x42c0
0x7 0x38 0xbc
0xf 0xe8 0xf4
0xc 0xb28 0x3798
0xb 0x58 0x294c
0x0 0x0 0x0
0x0 0x0 0x0
0x0 0x0 0x0
_MHDesc2
Handle TypeNameRva ObjectNameRva Attributes GrantedAccess HandleCount PointerCount ObjectInfoRva Reserved0
0x4 0x29b4 0x29cc 0x10 0x3 0x2d 0x54 0x0 0x0
0x8 0x29e6 0x0 0x0 0x100020 0x2 0x3 0x0 0x0
0xc 0x29f4 0x0 0x0 0x100020 0x2 0x3 0x0 0x0
0x10 0x2a02 0x0 0x0 0x100020 0x2 0x3 0x0 0x0
0x14 0x2a10 0x0 0x0 0x1f0000 0x2 0x5 0x0 0x0
EDIT
i have edited the code to print handle , type name , object name
and put it here
the results will be like
Handle TypeName ObjectName
0x4 Directory \KnownDlls
0x8 File No ObjName
0xc File No ObjName
0x10 File No ObjName
0x14 ALPC Port No ObjName
0x18 Key \REGISTRY\MACHINE\SYSTEM\ControlSet001\Control\Nls\Sorting\Versions
it should print all the 16.7 million handles in your dump if they exist
I have Raspberry Pi 3 and I use it as a Wi-Fi access point. I use Raspberry Pi 3 built-in Wi-Fi adapter for this.
Until today, the access point worked.
Today it stopped working. I think that Raspberry Pi crashed and I then turn the power off without shutting it down. Since then, it doesn't work.
If I run it as service, the status will show running (exited).
When I run it with sudo /usr/sbin/hostapd -dd /etc/hostapd/hostapd.conf, I get the following errors and it doesn't work:
random: Trying to read entropy from /dev/random
Configuration file: /etc/hostapd/hostapd.conf
rfkill: initial event: idx=0 type=1 op=0 soft=0 hard=0
rfkill: initial event: idx=1 type=2 op=0 soft=0 hard=0
nl80211: Supported cipher 00-0f-ac:1
nl80211: Supported cipher 00-0f-ac:5
nl80211: Supported cipher 00-0f-ac:2
nl80211: Supported cipher 00-0f-ac:4
nl80211: Using driver-based off-channel TX
nl80211: Supported vendor command: vendor_id=0x1018 subcmd=1
nl80211: Use separate P2P group interface (driver advertised support)
nl80211: Enable multi-channel concurrent (driver advertised support)
nl80211: use P2P_DEVICE support
nl80211: interface wlan0 in phy phy0
nl80211: Set mode ifindex 3 iftype 3 (AP)
nl80211: Setup AP(wlan0) - device_ap_sme=0 use_monitor=1
nl80211: Create interface iftype 6 (MONITOR)
Failed to create interface mon.wlan0: -95 (Operation not supported)
nl80211: Driver does not support monitor interface type - try to run without it
nl80211: Enable Probe Request reporting nl_preq=0x1516038
nl80211: Register frame type=0x40 (WLAN_FC_STYPE_PROBE_REQ) nl_handle=0x1516038 match=
nl80211: Register frame command failed (type=64): ret=-22 (Invalid argument)
nl80211: Register frame match - hexdump(len=0): [NULL]
nl80211: Failed to enable Probe Request frame reporting in AP mode
nl80211: QCA vendor test command returned -95 (Operation not supported)
nl80211: Add own interface ifindex 3
nl80211: if_indices[16]: 3
phy: phy0
BSS count 1, BSSID mask 00:00:00:00:00:00 (0 bits)
wlan0: interface state UNINITIALIZED->COUNTRY_UPDATE
Previous country code SI, new country code SI
nl80211: Regulatory information - country=SI (DFS-ETSI)
nl80211: 2402-2482 # 40 MHz 20 mBm
nl80211: 5170-5250 # 80 MHz 20 mBm
nl80211: 5250-5330 # 80 MHz 20 mBm (DFS)
nl80211: 5490-5710 # 160 MHz 27 mBm (DFS)
nl80211: 57000-66000 # 2160 MHz 40 mBm
nl80211: Added 802.11b mode based on 802.11g information
Allowed channel: mode=1 chan=1 freq=2412 MHz max_tx_power=20 dBm
Allowed channel: mode=1 chan=2 freq=2417 MHz max_tx_power=20 dBm
Allowed channel: mode=1 chan=3 freq=2422 MHz max_tx_power=20 dBm
Allowed channel: mode=1 chan=4 freq=2427 MHz max_tx_power=20 dBm
Allowed channel: mode=1 chan=5 freq=2432 MHz max_tx_power=20 dBm
Allowed channel: mode=1 chan=6 freq=2437 MHz max_tx_power=20 dBm
Allowed channel: mode=1 chan=7 freq=2442 MHz max_tx_power=20 dBm
Allowed channel: mode=1 chan=8 freq=2447 MHz max_tx_power=20 dBm
Allowed channel: mode=1 chan=9 freq=2452 MHz max_tx_power=20 dBm
Allowed channel: mode=1 chan=10 freq=2457 MHz max_tx_power=20 dBm
Allowed channel: mode=1 chan=11 freq=2462 MHz max_tx_power=20 dBm
Allowed channel: mode=1 chan=12 freq=2467 MHz max_tx_power=20 dBm
Allowed channel: mode=1 chan=13 freq=2472 MHz max_tx_power=20 dBm
Allowed channel: mode=0 chan=1 freq=2412 MHz max_tx_power=20 dBm
Allowed channel: mode=0 chan=2 freq=2417 MHz max_tx_power=20 dBm
Allowed channel: mode=0 chan=3 freq=2422 MHz max_tx_power=20 dBm
Allowed channel: mode=0 chan=4 freq=2427 MHz max_tx_power=20 dBm
Allowed channel: mode=0 chan=5 freq=2432 MHz max_tx_power=20 dBm
Allowed channel: mode=0 chan=6 freq=2437 MHz max_tx_power=20 dBm
Allowed channel: mode=0 chan=7 freq=2442 MHz max_tx_power=20 dBm
Allowed channel: mode=0 chan=8 freq=2447 MHz max_tx_power=20 dBm
Allowed channel: mode=0 chan=9 freq=2452 MHz max_tx_power=20 dBm
Allowed channel: mode=0 chan=10 freq=2457 MHz max_tx_power=20 dBm
Allowed channel: mode=0 chan=11 freq=2462 MHz max_tx_power=20 dBm
Allowed channel: mode=0 chan=12 freq=2467 MHz max_tx_power=20 dBm
Allowed channel: mode=0 chan=13 freq=2472 MHz max_tx_power=20 dBm
Completing interface initialization
Mode: IEEE 802.11g Channel: 11 Frequency: 2462 MHz
DFS 0 channels required radar detection
nl80211: Set freq 2462 (ht_enabled=0, vht_enabled=0, bandwidth=20 MHz, cf1=2462 MHz, cf2=0 MHz)
* freq=2462
* vht_enabled=0
* ht_enabled=0
RATE[0] rate=10 flags=0x1
RATE[1] rate=20 flags=0x1
RATE[2] rate=55 flags=0x1
RATE[3] rate=110 flags=0x1
RATE[4] rate=60 flags=0x0
RATE[5] rate=90 flags=0x0
RATE[6] rate=120 flags=0x0
RATE[7] rate=180 flags=0x0
RATE[8] rate=240 flags=0x0
RATE[9] rate=360 flags=0x0
RATE[10] rate=480 flags=0x0
RATE[11] rate=540 flags=0x0
hostapd_setup_bss(hapd=0x15159a0 (wlan0), first=1)
wlan0: Flushing old station entries
nl80211: flush -> DEL_STATION wlan0 (all)
nl80211: Station flush failed: ret=-14 (Bad address)
wlan0: Could not connect to kernel driver
wlan0: Deauthenticate all stations
nl80211: sta_remove -> DEL_STATION wlan0 ff:ff:ff:ff:ff:ff --> -110 (Connection timed out)
wpa_driver_nl80211_set_key: ifindex=3 (wlan0) alg=0 addr=(nil) key_idx=0 set_tx=0 seq_len=0 key_len=0
nl80211: set_key failed; err=-22 Invalid argument)
Failed to clear default encryption keys (ifname=wlan0 keyidx=0)
wpa_driver_nl80211_set_key: ifindex=3 (wlan0) alg=0 addr=(nil) key_idx=1 set_tx=0 seq_len=0 key_len=0
nl80211: set_key failed; err=-22 Invalid argument)
Failed to clear default encryption keys (ifname=wlan0 keyidx=1)
wpa_driver_nl80211_set_key: ifindex=3 (wlan0) alg=0 addr=(nil) key_idx=2 set_tx=0 seq_len=0 key_len=0
nl80211: set_key failed; err=-22 Invalid argument)
Failed to clear default encryption keys (ifname=wlan0 keyidx=2)
wpa_driver_nl80211_set_key: ifindex=3 (wlan0) alg=0 addr=(nil) key_idx=3 set_tx=0 seq_len=0 key_len=0
nl80211: set_key failed; err=-22 Invalid argument)
Failed to clear default encryption keys (ifname=wlan0 keyidx=3)
Using interface wlan0 with hwaddr b8:27:eb:e7:72:18 and ssid "RaspberryCar"
Deriving WPA PSK based on passphrase
SSID - hexdump_ascii(len=12):
52 61 73 70 62 65 72 72 79 43 61 72 RaspberryCar
PSK (ASCII passphrase) - hexdump_ascii(len=16): [REMOVED]
PSK (from passphrase) - hexdump(len=32): [REMOVED]
random: Got 20/20 bytes from /dev/random
Get randomness: len=32 entropy=0
GMK - hexdump(len=32): [REMOVED]
Get randomness: len=32 entropy=0
Key Counter - hexdump(len=32): [REMOVED]
WPA: Delay group state machine start until Beacon frames have been configured
nl80211: Set beacon (beacon_set=0)
nl80211: Beacon head - hexdump(len=63): 80 00 00 00 ff ff ff ff ff ff b8 27 eb e7 72 18 b8 27 eb e7 72 18 00 00 00 00 00 00 00 00 00 00 64 00 11 04 00 0c 52 61 73 70 62 65 72 72 79 43 61 72 01 08 82 84 8b 96 0c 12 18 24 03 01 0b
nl80211: Beacon tail - hexdump(len=37): 2a 01 04 32 04 30 48 60 6c 30 14 01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 00 0f ac 02 00 00 7f 04 00 00 00 02
nl80211: ifindex=3
nl80211: beacon_int=100
nl80211: dtim_period=2
nl80211: ssid - hexdump_ascii(len=12):
52 61 73 70 62 65 72 72 79 43 61 72 RaspberryCar
* beacon_int=100
nl80211: hidden SSID not in use
nl80211: privacy=1
nl80211: auth_algs=0x1
nl80211: wpa_version=0x2
nl80211: key_mgmt_suites=0x2
nl80211: pairwise_ciphers=0x18
nl80211: group_cipher=0x10
nl80211: beacon_ies - hexdump(len=6): 7f 04 00 00 00 02
nl80211: proberesp_ies - hexdump(len=6): 7f 04 00 00 00 02
nl80211: assocresp_ies - hexdump(len=6): 7f 04 00 00 00 02
nl80211: Beacon set failed: -110 (Connection timed out)
Failed to set beacon parameters
wlan0: Flushing old station entries
nl80211: flush -> DEL_STATION wlan0 (all)
nl80211: Station flush failed: ret=-14 (Bad address)
wlan0: Could not connect to kernel driver
wlan0: Deauthenticate all stations
nl80211: sta_remove -> DEL_STATION wlan0 ff:ff:ff:ff:ff:ff --> -110 (Connection timed out)
wpa_driver_nl80211_set_key: ifindex=3 (wlan0) alg=0 addr=(nil) key_idx=0 set_tx=0 seq_len=0 key_len=0
nl80211: set_key failed; err=-22 Invalid argument)
Failed to clear default encryption keys (ifname=wlan0 keyidx=0)
wpa_driver_nl80211_set_key: ifindex=3 (wlan0) alg=0 addr=(nil) key_idx=1 set_tx=0 seq_len=0 key_len=0
nl80211: set_key failed; err=-22 Invalid argument)
Failed to clear default encryption keys (ifname=wlan0 keyidx=1)
wpa_driver_nl80211_set_key: ifindex=3 (wlan0) alg=0 addr=(nil) key_idx=2 set_tx=0 seq_len=0 key_len=0
nl80211: set_key failed; err=-22 Invalid argument)
Failed to clear default encryption keys (ifname=wlan0 keyidx=2)
wpa_driver_nl80211_set_key: ifindex=3 (wlan0) alg=0 addr=(nil) key_idx=3 set_tx=0 seq_len=0 key_len=0
nl80211: set_key failed; err=-22 Invalid argument)
Failed to clear default encryption keys (ifname=wlan0 keyidx=3)
hostapd_free_hapd_data(wlan0)
Interface initialization failed
wlan0: interface state COUNTRY_UPDATE->DISABLED
wlan0: AP-DISABLED
wlan0: Unable to setup interface.
hostapd_interface_deinit_free(0x1514cd8)
hostapd_interface_deinit_free: num_bss=1 conf->num_bss=1
hostapd_interface_deinit(0x1514cd8)
wlan0: interface state DISABLED->DISABLED
hostapd_bss_deinit: deinit bss wlan0
wlan0: Deauthenticate all stations
nl80211: sta_remove -> DEL_STATION wlan0 ff:ff:ff:ff:ff:ff --> -110 (Connection timed out)
wlan0: AP-DISABLED
hostapd_cleanup(hapd=0x15159a0 (wlan0))
hostapd_free_hapd_data: Interface wlan0 wasn't started
hostapd_interface_deinit_free: driver=0xd8b84 drv_priv=0x1516328 -> hapd_deinit
nl80211: deinit ifname=wlan0 disabled_11b_rates=0
nl80211: Remove monitor interface: refcount=0
nl80211: Remove beacon (ifindex=3)
netlink: Operstate: ifindex=3 linkmode=0 (kernel-control), operstate=6 (IF_OPER_UP)
hostapd_interface_free(0x1514cd8)
hostapd_interface_free: free hapd 0x15159a0
hostapd_cleanup_iface(0x1514cd8)
hostapd_cleanup_iface_partial(0x1514cd8)
hostapd_cleanup_iface: free iface=0x1514cd8
This is my /etc/network/interfaces:
# interfaces(5) file used by ifup(8) and ifdown(8)
# Please note that this file is written to be used with dhcpcd
# For static IP, consult /etc/dhcpcd.conf and 'man dhcpcd.conf'
# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d
allow-hotplug wlan0
iface wlan0 inet manual
wireless-mode Master ### <--- It is same without this line
This is my /etc/hostapd/hostapd.conf:
interface=wlan0
driver=nl80211
ssid=RaspberryCar
hw_mode=g
channel=11
country_code=SI
wmm_enabled=0
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_passphrase=password
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP
And output of ifconfig:
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.64.127 netmask 255.255.255.0 broadcast 192.168.64.255
inet6 fe80::cc5e:510f:4686:fcb3 prefixlen 64 scopeid 0x20<link>
ether b8:27:eb:b2:27:4d txqueuelen 1000 (Ethernet)
RX packets 10883 bytes 709212 (692.5 KiB)
RX errors 0 dropped 2 overruns 0 frame 0
TX packets 2471 bytes 500246 (488.5 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 800 bytes 55840 (54.5 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 800 bytes 55840 (54.5 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
wlan0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether b8:27:eb:e7:72:18 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Access point started working now, but I didn't change anything. Maybe there were some corrupted files, but the system repaired them after a few reboots.
I also got answers on Raspberry Pi Forums by epoch1970. I don't know if they would fix the problem, but they are mostly about corrupted files, so they probably fix the problems.
In SID2E and SID22 is there a condition where the length of the entire frame will exceed 7 bytes?
If yes then how it will send or write tha data bytes?
Yes, it is a common use-case in UDS that the response to SID 0x22 (ReadDataByIdentifier) or the request to SID 0x2E (WriteDataByIdentifier) exceeds 7 bytes in length. For this purpose a message consisting of multple CAN frames is
sent, utilizing the Transport-Layer (ISO-TP, ISO 15765-2).
Consider a normal single frame message, where the high-nibble of the first byte is 0x0 i.e.
0x7E0 0x03 0x22 0xF1 0x90
0x7E8 0x04 0x62 0xF1 0x90 0x01
Here the payload is within 7 bytes (in both request and response), so the low-nibble of the first byte tells us the exact length (0x03 in the request, 0x04 in the response). As the complete message fits within a single CAN frame, nothing else is required. But to send a longer diagnostic message, it needs to be splitted across multple CAN frames (segmentation). For this 3 different types of messages are required:
A first frame is sent to the receiver to start the transmission.
This contains the length (up to 4095 bytes) of the complete payload
data and the first 6 bytes of the message. The high-nibble 0x1 of
the first byte indicates that the message is a first frame.
A flow control frame confirming receiving of the first frame is
replied to the sender of the first frame. It contains additional
information like expected STmin timing and block-size. The
high-nibble 0x3 of the first byte indicates that the message is a
flow control frame.
One or more consecutive frames are sent to the receiver, which
contain up to 7 bytes of the remaining payload - together with a
counter to ensure the data can be desegmented in the correct order.
The high-nibble 0x2 of the first byte indicates that the message is
a consecutive frame.
Now consider the following scenario: The tester application sends the single frame 0x7E0 0x03 0x22 0xF1 0x90 as request. The ECU may want to send the response 0x62 0xF1 0x90 0x01 0x02 0x03 0x04 0x05 (8 bytes payload) to the tester application.
So the ECU will first send the first frame:
0x7E8 0x10 0x08 0x62 0xF1 0x90 0x01 0x02 0x03
And wait for a flow control frame from the tester application:
0x7E0 0x30 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Then the ECU will continue to send consecutive frames until the
complete message is transmitted:
0x7E8 0x21 0x04 0x05 0x00 0x00 0x00 0x00 0x00
For the SID 0x2E (WriteDataByIdentifier) it will be very similar, just the roles are reversed as typically the tester application wants to send the long message in the request and the ECU will reply with the flow control message. i.e.
0x7E0 0x10 0x08 0x2E 0xF1 0x90 0x01 0x02 0x03
0x7E8 0x30 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x7E0 0x21 0x04 0x05 0x00 0x00 0x00 0x00 0x00
0x7E8 0x03 0x6E 0xF1 0x90 0x00 0x00 0x00 0x00
If more than one consecutive frame is required, the first byte will simply be increased from 0x21 up to 0x2F and then start again from 0x20 to count up.
0x7E0 0x10 0x76 0x2E 0xF1 0x90 0x01 0x02 0x03
0x7E8 0x30 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x7E0 0x21 0x04 0x05 0x06 0x07 0x08 0x09 0x0A
0x7E0 0x22 0x0B 0x0C 0x0D 0x0E 0x0F 0x10 0x11
...
0x7E0 0x2F 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0x7E0 0x20 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
I am writing the instruction below.
movq $TARGET_CIA, %rcx
TARGET_CIA is an undefined variable so is treated as zero. This instruction's disassembly looks like
0: 48 c7 c1 00 00 00 00 mov $0x0,%rcx
At run time, I want to replace this $TARGET_CIA with a 64-bit value by copying the 64-bit value to the offset of TARGET_CIA symbol. Please let me know how this can this be done.
In fasm you would achieve that with "mov [qword 0], rax". Note that AL, AX, EAX, RAX are the only registers allowed to be the source or destination of an instruction with 64-bit absolute addressing so you won't be able to use RCX here (copy the value to RAX)
If your assembler has no means to force full addressing, then use:
db 0x48, 0xA3, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00