Is there any tool which can help in finding record size in berkley DB?
https://www.oracle.com/in/database/technologies/related/berkeleydb.html
db_dump (1) has them. For example, on an RHEL/Centos Linux system, use -da to dump all debug information:
db_dump -da /var/lib/rpm/Name | head -100
...
[000] 4088 len: 5 data: CUnit
[001] 4076 len: 8 data: 8d05000000000000
[002] 4060 len: 11 data: CUnit-devel
[003] 4048 len: 8 data: 5006000000000000
[004] 4040 len: 5 data: GeoIP
[005] 4028 len: 8 data: 7105000000000000
[006] 4008 len: 14 data: NetworkManager
[007] 3996 len: 8 data: d705000000000000
Related
I'm using Raspberry Pi to connect with Minew S1 Temperature and Humidity Sensor, in order to connect with my sensor I need to send some data to connect with sensor, so at first I tried connect with BeaconSet+ app with sensor, and I captured all those packets and tried to decode those using wireshark, so the first data sent from mobile to sensor is "Read By Group Type Request", what does it mean and how can I mirror it in Raspberry Pi using gatttool or bluetoothctl.
this link has packet screenshot
> HCI Event: Command Complete (0x0e) plen 4 #37 [hci0] 23.110065
LE Set Scan Enable (0x08|0x000c) ncmd 1
Status: Success (0x00)
< HCI Command: LE Create Connection (0x08|0x000d) plen 25 #38 [hci0] 23.110095
Scan interval: 60.000 msec (0x0060)
Scan window: 60.000 msec (0x0060)
Filter policy: White list is not used (0x00)
Peer address type: Public (0x00)
Peer address: AC:23:3F:AB:7B:D8 (Shenzhen Minew Technologies Co., Ltd.)
Own address type: Public (0x00)
Min connection interval: 30.00 msec (0x0018)
Max connection interval: 50.00 msec (0x0028)
Connection latency: 0 (0x0000)
Supervision timeout: 420 msec (0x002a)
Min connection length: 0.000 msec (0x0000)
Max connection length: 0.000 msec (0x0000)
> HCI Event: Command Status (0x0f) plen 4 #39 [hci0] 23.110613
LE Create Connection (0x08|0x000d) ncmd 1
Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 19 #40 [hci0] 23.210757
LE Connection Complete (0x01)
Status: Success (0x00)
Handle: 64
Role: Master (0x00)
Peer address type: Public (0x00)
Peer address: AC:23:3F:AB:7B:D8 (Shenzhen Minew Technologies Co., Ltd.)
Connection interval: 48.75 msec (0x0027)
Connection latency: 0 (0x0000)
Supervision timeout: 420 msec (0x002a)
Master clock accuracy: 0x00
# MGMT Event: Device Connected (0x000b) plen 37 {0x0001} [hci0] 23.210785
LE Address: AC:23:3F:AB:7B:D8 (Shenzhen Minew Technologies Co., Ltd.)
Flags: 0x00000000
Data length: 24
Flags: 0x06
LE General Discoverable Mode
BR/EDR Not Supported
16-bit Service UUIDs (complete): 1 entry
Unknown (0xffe1)
Service Data (UUID 0xffe1): a101641cfd48e6d87bab3f23ac
< HCI Command: LE Read Remote Used Features (0x08|0x0016) plen 2 #41 [hci0] 23.210905
Handle: 64
> HCI Event: Command Status (0x0f) plen 4 #42 [hci0] 23.211771
LE Read Remote Used Features (0x08|0x0016) ncmd 1
Status: Success (0x00)
> HCI Event: Command Complete (0x0e) plen 14 #43 [hci0] 23.211775
LE Read Remote Used Features (0x08|0x0016) ncmd 1
Status: Success (0x00)
00 00 00 00 00 00 00 00 00 00 ..........
> HCI Event: LE Meta Event (0x3e) plen 12 #44 [hci0] 23.337233
LE Read Remote Used Features (0x04)
Status: Success (0x00)
Handle: 64
Features: 0x21 0x00 0x00 0x00 0x00 0x00 0x00 0x00
LE Encryption
LE Data Packet Length Extension
< ACL Data TX: Handle 64 flags 0x00 dlen 7 #45 [hci0] 23.337677
ATT: Exchange MTU Request (0x02) len 2
Client RX MTU: 517
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #46 [hci0] 23.532018
ATT: Exchange MTU Response (0x03) len 2
Server RX MTU: 23
< ACL Data TX: Handle 64 flags 0x00 dlen 7 #47 [hci0] 23.532452
ATT: Read Request (0x0a) len 2
Handle: 0x0003
> HCI Event: Number of Completed Packets (0x13) plen 5 #48 [hci0] 23.580957
Num handles: 1
Handle: 64
Count: 2
> ACL Data RX: Handle 64 flags 0x02 dlen 10 #49 [hci0] 23.629552
ATT: Read Response (0x0b) len 5
Value: 6e52463578
< ACL Data TX: Handle 64 flags 0x00 dlen 7 #50 [hci0] 23.629713
ATT: Read Request (0x0a) len 2
Handle: 0x0005
> ACL Data RX: Handle 64 flags 0x02 dlen 7 #51 [hci0] 23.727010
ATT: Read Response (0x0b) len 2
Value: 0000
< ACL Data TX: Handle 64 flags 0x00 dlen 7 #52 [hci0] 23.727179
ATT: Read Request (0x0a) len 2
Handle: 0x0027
> HCI Event: Number of Completed Packets (0x13) plen 5 #53 [hci0] 23.775948
Num handles: 1
Handle: 64
Count: 2
> HCI Event: Disconnect Complete (0x05) plen 4 #54 [hci0] 32.502249
Status: Success (0x00)
Handle: 64
Reason: Remote User Terminated Connection (0x13)
# MGMT Event: Device Disconnected (0x000c) plen 8 {0x0001} [hci0] 32.502320
LE Address: AC:23:3F:AB:7B:D8 (Shenzhen Minew Technologies Co., Ltd.)
Reason: Connection terminated by remote host (0x03)
Thank you.
Can anyone guide me on the following?
I'm trying to figure out the answer as seen in the first question inside the blog malwarejake[.]blogspot.com/2015/05/packet-analysis-practice-part-3.html .
As per sample packet found
What is the embedded protocol, the destination port, and the amount of data not including protocol headers?
0x0000: 4500 004c 1986 4000 4006 9cba c0a8 0165
0x0010: c0a8 01b6 0015 bf3c dad0 5039 2a8c 25be
0x0020: 8018 0072 06ec 0000 0101 080a 008a 70ac
The answer for the above question is as above.
Embedded protocol: TCP
Total packet length: 76
IP Header length: 20
Protocol header length: 32
Data length: 24
Dest Port: 0xbf3c (48956)
I managed to get all the other answer with the exception of Protocol Header Length and Data Length.
Isn't TCP Header Length normally 20 bytes with the extension up to 40 bytes? But how is 32 bytes derived from the above packet? I don't understand.
Thanks!
Here's the TCP Header directly from the RFC:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| Window |
| | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The values 0015 and bf3c are the ports.
The values dad0 5039 and 2a8c 25be are the sequence/ack numbers.
Now take a look at the next 4 bits. The ones at offset 0x20. The value of the byte is 0x80, which means that the topmost 4 bits are 1000. They correspond to the "data offset" field:
Data Offset: 4 bits
The number of 32 bit words in the TCP Header. This indicates where
the data begins. The TCP header (even one including options) is an
integral number of 32 bits long.
So 1000 means that the header consists of 8 x 32-bit words, which means 8 x 4 bytes = 32 bytes.
I am trying to monitor the memory usage of kamailio. The PKG memory I have arranged, though the shared memory is something else.
According to documentation you can get the shared memory like this:
kamcmd mod.stats all shm
In my case, I get the following:
Module: core
{
msg_lump_cloner(984): 1560
dns_cache_mk_bad_entry(867): 192
dns_cache_mk_rd_entry(1216): 232
build_req_buf_from_sip_req(2155): 2752
sip_msg_shm_clone(495): 822664
tcpconn_new(957): 16416728
counters_prefork_init(207): 30720
cfg_clone_str(130): 208
cfg_shmize(217): 976
init_pt(105): 4200
cfg_parse_str(906): 80
init_pt(106): 16
init_pt(111): 40
create_avp(175): 10368
register_timer(1012): 720
cfg_register_ctx(47): 128
init_tcp(4643): 8192
init_tcp(4637): 32768
init_tcp(4629): 8
init_tcp(4622): 8
init_tcp(4615): 8
init_tcp(4609): 8
init_tcp(4597): 8
init_avps(90): 8
init_avps(89): 8
init_dst_blacklist(437): 16384
init_dst_blacklist(430): 8
timer_alloc(515): 96
init_dns_cache(366): 8
init_dns_cache(358): 16384
init_dns_cache(351): 16
init_dns_cache(345): 8
init_timer(284): 8
init_timer(283): 16384
init_timer(282): 8
init_timer(281): 8
init_timer(270): 8
init_timer(238): 8
init_timer(221): 278544
init_timer(220): 8
init_timer(207): 8
cfg_child_cb_new(830): 64
sr_cfg_init(361): 8
sr_cfg_init(354): 8
sr_cfg_init(347): 8
sr_cfg_init(335): 8
sr_cfg_init(323): 24
shm_core_lock_init(153): 8
Total: 17660616
}
... [ list of modules here, snipped because not relevant I think] ...
So I guess the one I need is Total: 17660616.
However, what does this mean? Is it the total allocated memory? Available memory?
The commands you used is for seeing the used of shared memory per module.
If you want the statistics for total used and free shared memory, then use the command:
kamctl stats shmem
or:
kamcmd stats.get_statistics shmem:
The output will be like:
shmem:fragments = 179
shmem:free_size = 127471848
shmem:max_used_size = 7269016
shmem:real_used_size = 6745880
shmem:total_size = 134217728
shmem:used_size = 5106728
The free_size value is the one you have to monitor for available shared memory.
I have written one http put client(use libcurl libarary) to put file into apache webdav server, and use tcpdump catch the packet at the server side, then use tcptrace (www.tcptrace.org) to analysis the dump file, below is the result:
Host a is the client side, Host b is the server side:
a->b: b->a:
total packets: 152120 total packets: 151974
ack pkts sent: 152120 ack pkts sent: 151974
pure acks sent: 120 pure acks sent: 151854
sack pkts sent: 0 sack pkts sent: 0
dsack pkts sent: 0 dsack pkts sent: 0
max sack blks/ack: 0 max sack blks/ack: 0
unique bytes sent: 3532149672 unique bytes sent: 30420
actual data pkts: 152000 actual data pkts: 120
actual data bytes: 3532149672 actual data bytes: 30420
rexmt data pkts: 0 rexmt data pkts: 0
rexmt data bytes: 0 rexmt data bytes: 0
zwnd probe pkts: 0 zwnd probe pkts: 0
zwnd probe bytes: 0 zwnd probe bytes: 0
outoforder pkts: 0 outoforder pkts: 0
pushed data pkts: 3341 pushed data pkts: 120
SYN/FIN pkts sent: 0/0 SYN/FIN pkts sent: 0/0
req 1323 ws/ts: N/Y req 1323 ws/ts: N/Y
urgent data pkts: 0 pkts urgent data pkts: 0 pkts
urgent data bytes: 0 bytes urgent data bytes: 0 bytes
mss requested: 0 bytes mss requested: 0 bytes
max segm size: 31856 bytes max segm size: 482 bytes
min segm size: 216 bytes min segm size: 25 bytes
avg segm size: 23237 bytes avg segm size: 253 bytes
max win adv: 125 bytes max win adv: 5402 bytes
min win adv: 125 bytes min win adv: 5402 bytes
zero win adv: 0 times zero win adv: 0 times
avg win adv: 125 bytes avg win adv: 5402 bytes
initial window: 15928 bytes initial window: 0 bytes
initial window: 1 pkts initial window: 0 pkts
ttl stream length: NA ttl stream length: NA
missed data: NA missed data: NA
truncated data: 0 bytes truncated data: 0 bytes
truncated packets: 0 pkts truncated packets: 0 pkts
data xmit time: 151.297 secs data xmit time: 150.696 secs
idletime max: 44571.3 ms idletime max: 44571.3 ms
throughput: 23345867 Bps throughput: 201 Bps
RTT samples: 151915 RTT samples: 120
RTT min: 0.0 ms RTT min: 0.1 ms
RTT max: 0.3 ms RTT max: 40.1 ms
RTT avg: 0.0 ms RTT avg: 19.9 ms
RTT stdev: 0.0 ms RTT stdev: 19.8 ms
RTT from 3WHS: 0.0 ms RTT from 3WHS: 0.0 ms
RTT full_sz smpls: 74427 RTT full_sz smpls: 60
RTT full_sz min: 0.0 ms RTT full_sz min: 39.1 ms
RTT full_sz max: 0.3 ms RTT full_sz max: 40.1 ms
RTT full_sz avg: 0.0 ms RTT full_sz avg: 39.6 ms
RTT full_sz stdev: 0.0 ms RTT full_sz stdev: 0.3 ms
post-loss acks: 0 post-loss acks: 0
segs cum acked: 89 segs cum acked: 0
duplicate acks: 0 duplicate acks: 0
triple dupacks: 0 triple dupacks: 0
max # retrans: 0 max # retrans: 0
min retr time: 0.0 ms min retr time: 0.0 ms
max retr time: 0.0 ms max retr time: 0.0 ms
avg retr time: 0.0 ms avg retr time: 0.0 ms
sdv retr time: 0.0 ms sdv retr time: 0.0 ms
According the result above, the RTT of client to server is small, but the server side to client side is large. Can anyone help explain this from me?
Because this
unique bytes sent: 3532149672 unique bytes sent: 30420
actual data pkts: 152000 actual data pkts: 120
actual data bytes: 3532149672 actual data bytes: 30420
a->b is sending a steady flow of data, which ensures buffers get filled and things get pushed.
b->a is only sending a few acks etc, doing next to nothing at all, so as a result things get left in buffers for a while (a few ms).
In addition to that, RTT is round trip time. It's the time from when the application queues a packet for sending and when the corresponding response is received. Since the host on a is busy pushing data, and probably filling its own buffers, there's going to be a small amount of additional overhead for something from b to get acknowledged.
Firstly host b sent very little data (a very small sample size). Secondly, I suspect that host a has an asymmetrical Internet connection (e.g. 10MB/1MB).
I'm trying to find a way to convert files in a little-used archaic file format into something human readable...
As an example, od -x myfile gives:
0000000 2800 4620 1000 461e c800 461d a000 461e
0000020 8000 461e 2800 461e 5000 461f b800 461e
0000040 b800 461d 4000 461c a000 461e 3800 4620
0000060 f800 4621 7800 462a e000 4622 2800 463c
0000100 2000 464a 1000 4654 8c00 4693 5000 4661
0000120 7000 46ac 6c00 46d1 a400 4695 3c00 470a
0000140 b000 46ca 7400 46e9 c200 471b 9400 469e
0000160 9c00 4709 cc00 4719 4000 46b0 6400 46cc
...
which I know corresponds to these integers:
10250 10116 10098 10152 10144 10122 10196 10158
10094 10000 10152 10254 10366 10910 10424 12042
12936 13572 18886 14420 22072 ...
but I have no idea how to convert one to the other!!
Many many thanks to anyone who can help.
If possible, general tips for what to try/where to begin in this situation would also be appreciated.
Update: I put the full binary file online here http://pastebin.com/YL2ApExG and the numbers it corresponds to here http://pastebin.com/gXNntsaJ
In the hex dump, it seems to alternate between four digits, presumably they correspond to the numbers I want? separated either by 4600 or 4700. Unfortunately, I don't know where to go from here!
Someone else asked below: the binary file is a .dat file generated by an old spectroscopy program... it's 1336 bytes and corresponds to 334 integers, so it's four bytes per integer.
Well this is what you can do -
Step I: Do the od -x of the file and redirect it to a temp file (eg. hexdump.txt)
od -x myfile > hexdump.txt
Step II: You will now have a text file that contains hexadecimal values which you can view using the cat command. Something like this -
[jaypal~/Temp]$ cat hexdump.txt
0000000 2800 4620 1000 461e c800 461d a000 461e
0000020 8000 461e 2800 461e 5000 461f b800 461e
0000040 b800 461d 4000 461c a000 461e 3800 4620
0000060 f800 4621 7800 462a e000 4622 2800 463c
0000100 2000 464a 1000 4654 8c00 4693 5000 4661
0000120 7000 46ac 6c00 46d1 a400 4695 3c00 470a
0000140 b000 46ca 7400 46e9 c200 471b 9400 469e
0000160 9c00 4709 cc00 4719 4000 46b0 6400 46cc
Step III: The first column isn't really important to you. Columns 2 thru 9 are important. We will now strip the file using AWK so that you can convert it to decimal. We will add space so that we can consider each value as an individual field. We will also add "0x" to it so that we can pass it as a hexadecimal value.
[jaypal~/Temp]$ awk '{for (i=2;i<=NF;i++) printf "0x"$i" "}' hexdump.txt > hexdump1.txt
[jaypal~/Temp]$ cat hexdump1.txt
0x2800 0x4620 0x1000 0x461e 0xc800 0x461d 0xa000 0x461e 0x8000 0x461e 0x2800 0x461e 0x5000 0x461f 0xb800 0x461e 0xb800 0x461d 0x4000 0x461c 0xa000 0x461e 0x3800 0x4620 0xf800 0x4621 0x7800 0x462a 0xe000 0x4622 0x2800 0x463c 0x2000 0x464a 0x1000 0x4654 0x8c00 0x4693 0x5000 0x4661 0x7000 0x46ac 0x6c00 0x46d1 0xa400 0x4695 0x3c00 0x470a 0xb000 0x46ca 0x7400 0x46e9 0xc200 0x471b 0x9400 0x469e 0x9c00 0x4709 0xcc00 0x4719 0x4000 0x46b0 0x6400 0x46cc
Step IV: Now we will convert each hexadecimal value into decimal using printf function with AWK.
[jaypal~/Temp]$ gawk --non-decimal-data '{ for (i=1;i<=NF;i++) printf ("%05d ", $i)}' hexdump1.txt > hexdump2.txt
[jaypal~/Temp]$ cat hexdump2.txt
10240 17952 04096 17950 51200 17949 40960 17950 32768 17950 10240 17950 20480 17951 47104 17950 47104 17949 16384 17948 40960 17950 14336 17952 63488 17953 30720 17962 57344 17954 10240 17980 08192 17994 04096 18004 35840 18067 20480 18017 28672 18092 27648 18129 41984 18069 15360 18186 45056 18122 29696 18153 49664 18203 37888 18078 39936 18185 52224 18201 16384 18096 25600 18124
Step V: Formatting to make it easily readable
[jaypal~/Temp]$ sed 's/.\{48\}/&\n/g' < hexdump2.txt > hexdump3.txt
[jaypal~/Temp]$ cat hexdump3.txt
10240 17952 04096 17950 51200 17949 40960 17950
32768 17950 10240 17950 20480 17951 47104 17950
47104 17949 16384 17948 40960 17950 14336 17952
63488 17953 30720 17962 57344 17954 10240 17980
08192 17994 04096 18004 35840 18067 20480 18017
28672 18092 27648 18129 41984 18069 15360 18186
45056 18122 29696 18153 49664 18203 37888 18078
39936 18185 52224 18201 16384 18096 25600 18124