UnixODBC Cannot Query Pervasive SQL Database - freetds
I am using Ubuntu 14.04 on a VM to try and connect to a Pervasive SQL (V12) database hosted on a Windows 10 machine.
I have tested the networking and I can telnet into the pervasive server with:
telnet 192.168.0.2 1583
But when it comes to using isql/tsql/osql I just cannot get a connection to the Pervasive server so that I can query the database.
I have spent four weeks on this and gotten to the point now where it almost works.
So when running this command in terminal:
root#test.dev:~# TDSDUMPCONFIG=stderr TDSDUMP=stderr tsql -S PSQL -U admin -P MASTER
I get the following output:
log.c:167:Starting log file for FreeTDS 0.95.95
on 2016-05-20 10:11:02 with debug flags 0x4fff.
config.c:168:Getting connection information for [PSQL].
config.c:172:Attempting to read conf files.
config.c:353:... $FREETDSCONF not set. Trying $FREETDS/etc.
config.c:366:... $FREETDS not set. Trying $HOME.
config.c:296:Found conf file '/root/.freetds.conf' (.freetds.conf).
config.c:495:Looking for section global.
config.c:554: Found section global.
config.c:557:Got a match.
config.c:580: tds version = '4.2'
config.c:886:Setting tds version to 4.2 (0x402).
config.c:580: dump file = '/tmp/freetds.log'
config.c:580: timeout = '10'
config.c:580: connect timeout = '10'
config.c:580: text size = '64512'
config.c:554: Found section psql.
config.c:568: Reached EOF
config.c:495:Looking for section PSQL.
config.c:554: Found section global.
config.c:554: Found section psql.
config.c:557:Got a match.
config.c:580: host = '192.168.0.2'
config.c:617:Found host entry 192.168.0.2
config.c:620:IP addr is 192.168.0.2.
config.c:580: port = '1583'
config.c:580: client charset = 'UTF-8'
config.c:635:tds_parse_conf_section: client charset is UTF-8.
config.c:580: tds version = '5.0'
config.c:886:Setting tds version to 5.0 (0x500).
config.c:568: Reached EOF
config.c:300:Success: [PSQL] defined in /root/.freetds.conf.
config.c:765:Setting 'dump_file' to 'stderr' from $TDSDUMP.
config.c:213:Final connection parameters:
config.c:214: server_name = PSQL
config.c:215: server_host_name = 192.168.0.2
config.c:218: ip_addr = 192.168.0.2
config.c:223: instance_name =
config.c:224: port = 1583
config.c:225: major_version = 5
config.c:226: minor_version = 0
config.c:227: block_size = 0
config.c:228: language = us_english
config.c:229: server_charset =
config.c:230: connect_timeout = 10
config.c:231: client_host_name = sails.dev
config.c:232: client_charset = UTF-8
config.c:233: use_utf16 = 0
config.c:234: app_name = TSQL
config.c:235: user_name = admin
config.c:238: library = TDS-Library
config.c:239: bulk_copy = 0
config.c:240: suppress_language = 0
config.c:241: encrypt level = 0
config.c:242: query_timeout = 10
config.c:245: database =
config.c:246: dump_file = stderr
config.c:247: debug_flags = 0
config.c:248: text_size = 64512
config.c:249: emul_little_endian = 0
config.c:250: server_realm_name =
config.c:251: server_spn =
config.c:252: cafile =
config.c:253: crlfile =
config.c:254: check_ssl_hostname = 1
log.c:167:Starting log file for FreeTDS 0.95.95
on 2016-05-20 10:11:02 with debug flags 0x4fff.
locale is "en_ZA.UTF-8"
locale charset is "UTF-8"
using default charset "UTF-8"
iconv.c:328:tds_iconv_open(0x641370, UTF-8)
iconv.c:187:local name for ISO-8859-1 is ISO-8859-1
iconv.c:187:local name for UTF-8 is UTF-8
iconv.c:187:local name for UCS-2LE is UCS-2LE
iconv.c:187:local name for UCS-2BE is UCS-2BE
iconv.c:346:setting up conversions for client charset "UTF-8"
iconv.c:348:preparing iconv for "UTF-8" <-> "UCS-2LE" conversion
iconv.c:395:preparing iconv for "ISO-8859-1" <-> "ISO-8859-1" conversion
iconv.c:400:tds_iconv_open: done
net.c:202:Connecting to 192.168.0.2 port 1583 (TDS version 5.0)
net.c:275:tds_open_socket: connect(2) returned "Operation now in progress"
net.c:314:tds_open_socket() succeeded
packet.c:740:Sending packet
0000 02 00 02 00 00 00 00 00-73 61 69 6c 73 2e 64 65 |........ sails.de|
0010 76 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 |v....... ........|
0020 00 00 00 00 00 00 09 61-64 6d 69 6e 00 00 00 00 |.......a dmin....|
0030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 |........ ........|
0040 00 00 00 00 00 05 4d 41-53 54 45 52 00 00 00 00 |......MA STER....|
0050 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 |........ ........|
0060 00 00 00 00 06 36 32 33-33 00 00 00 00 00 00 00 |.....623 3.......|
0070 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 |........ ........|
0080 00 00 00 04 03 01 06 0a-09 01 00 00 00 00 00 00 |........ ........|
0090 00 00 00 00 54 53 51 4c-00 00 00 00 00 00 00 00 |....TSQL ........|
00a0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 |........ ........|
00b0 00 00 04 50 53 51 4c 00-00 00 00 00 00 00 00 00 |...PSQL. ........|
00c0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 |........ ........|
00d0 00 04 00 06 4d 41 53 54-45 52 00 00 00 00 00 00 |....MAST ER......|
00e0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 |........ ........|
00f0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 |........ ........|
0100 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 |........ ........|
0110 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 |........ ........|
0120 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 |........ ........|
0130 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 |........ ........|
0140 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 |........ ........|
0150 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 |........ ........|
0160 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 |........ ........|
0170 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 |........ ........|
0180 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 |........ ........|
0190 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 |........ ........|
01a0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 |........ ........|
01b0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 |........ ........|
01c0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 |........ ........|
01d0 00 08 05 00 00 00 54 44-53 2d 4c 69 62 72 61 72 |......TD S-Librar|
01e0 0a 05 00 00 00 00 0d 11-75 73 5f 65 6e 67 6c 69 |........ us_engli|
01f0 73 68 00 00 00 00 00 00-00 00 00 00 00 00 00 00 |sh...... ........|
packet.c:740:Sending packet
0000 02 01 00 65 00 00 00 00-00 00 00 00 00 00 0a 00 |...e.... ........|
0010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 |........ ........|
0020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 |........ ........|
0030 00 00 00 00 00 00 00 00-00 00 00 00 01 35 31 32 |........ .....512|
0040 00 00 00 03 00 00 00 00-e2 1a 00 01 0b 08 00 01 |........ ........|
0050 e8 0f 6d 7f ff ff ff fe-02 0b 00 00 00 00 00 00 |..m..... ........|
0060 02 68 00 00 00 - |.h...|
token.c:327:tds_process_login_tokens()
query.c:3772:tds_disconnect()
mem.c:648:tds_free_all_results()
util.c:165:Changed query state from IDLE to WRITING
util.c:165:Changed query state from WRITING to PENDING
packet.c:740:Sending packet
0000 0f 01 00 0a 00 00 00 00-71 00 |........ q.|
token.c:550:tds_process_tokens(0x641370, 0x7ffee7182238, 0x7ffee718223c, 0x100)
util.c:165:Changed query state from PENDING to READING
query.c:3772:tds_disconnect()
util.c:165:Changed query state from READING to DEAD
token.c:565:processing result tokens. marker is 0()
token.c:116:tds_process_default_tokens() marker is 0()
token.c:119:leaving tds_process_default_tokens() connection dead
util.c:83:logic error: cannot change query state from DEAD to PENDING
util.c:165:Changed query state from DEAD to DEAD
util.c:322:tdserror(0x63f400, 0x641370, 20056, 9)
util.c:358:tdserror: client library not called because either tds_ctx (0x63f400) or tds_ctx->err_handler is NULL
util.c:375:tdserror: returning TDS_INT_CANCEL(2)
token.c:336:looking for login token, got 0()
token.c:116:tds_process_default_tokens() marker is 0()
token.c:119:leaving tds_process_default_tokens() connection dead
login.c:472:login packet accepted
util.c:322:tdserror(0x63f400, 0x641370, 20002, 0)
util.c:358:tdserror: client library not called because either tds_ctx (0x63f400) or tds_ctx->err_handler is NULL
util.c:375:tdserror: returning TDS_INT_CANCEL(2)
mem.c:648:tds_free_all_results()
There was a problem connecting to the server
And I have no idea what to try next so that I can query the data in the database.
I have tried all tds versions, tds drivers and pervasive ODBC drivers to no avail.
Any insight into what can be acertained from the above log and/or what I might be doing wrong would be greatly appreciated, thank you!
Create a ClientDSN usind dsnadd (docs).
Once the DSN is set up, test using the psql user and isql and then follow the instructions for "Using Utilities from Users Other than psql" for using another user. As noted in comments, copy the contents of /home/psql/.bashrc to the /root/.bashrc.
Related
SNMP - Decode Hex String Value Epson L395
This is my first question here, so hope it's correctly done. Im trying to get some information from a Epson L365. The thing is when i try to get the Total page printed, I get the response in HEX-String .1.3.6.1.4.1.1248.1.2.2.1.1.1.4.1 0x40 42 44 43 20 53 54 32 0D 0A 62 00 01 01 04 06 02 01 00 0F 0D 03 01 00 69 03 01 69 04 02 69 05 03 69 10 03 01 09 4E 13 01 01 19 0C 00 00 00 00 00 75 6E 6B 6E 6F 77 6E 24 02 00 00 28 04 FF 01 00 00 2F 01 01 36 14 FF FF FF FF FF FF FF FF DB 2C 00 00 09 09 00 00 A0 00 00 00 37 05 02 00 00 00 00 40 0A 58 32 4E 5A 34 36 31 33 39 31 OctetString And this is the response that I get .1.3.6.1.4.1.1248.1.2.2.1.1.1.4.1 #BDC ST2 b......... ...i..i..i..i... N..........unknown$...(...../..6..........,.. ......7......# X2NZ461391 OctetString I have already researched and do not know where to go.
Counting people using wifi packets when phones have randomized mac ids
I want to build a system for counting people based on wifi packets. I am using esp8266 for sniffing packets. But i read that android and iphones are now randomizing mac ids when they are not connected to any network. I thought of using probe requests but i saw that whenever i press refresh in mobile, the mac address is changed. So my program would detect it as a new device. This is what i am getting in different packets from the same device. Mac Address - da a1 19 9f bb 5c d4 10 68 50 00 00 00 00 00 00 05 00 40 00 00 00 ff ff ff ff ff ff **da a1 19 9f bb 5c** ff ff ff ff ff ff e0 a4 00 0b 77 69 66 69 63 68 61 68 69 79 65 01 04 02 04 0b 16 32 08 0c 12 18 24 30 48 60 6c 03 01 04 2d 1a 6e 01 03 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 dd 07 00 50 f2 08 00 00 00 7f 05 00 00 0a 02 01 3d 16 04 05 01 00 00 00 00 00 00 00 01 00 68 00 Mac Address - da a1 19 00 44 2f d3 10 2e 50 00 00 00 00 00 00 0c 00 40 00 00 00 ff ff ff ff ff ff **da a1 19 00 44 2f** ff ff ff ff ff ff 90 c1 00 00 01 08 02 04 0b 16 0c 12 18 24 32 04 30 48 60 6c 00 00 34 34 50 43 01 08 82 84 8b 96 12 24 48 6c 03 01 0b 32 04 0c 18 30 60 07 06 49 4e 20 01 0d 14 23 02 13 00 46 05 f3 c0 01 00 04 05 04 00 01 00 14 dd 1a 00 50 f2 01 01 00 00 50 f2 02 02 00 00 50 f2 02 00 50 01 00 2e 00 Mac Address - da a1 19 ea d3 58 d7 10 67 50 00 00 00 00 00 00 03 00 40 00 00 00 ff ff ff ff ff ff **da a1 19 ea d3 58** ff ff ff ff ff ff a0 c2 00 0a 5a 54 45 2d 4b 62 72 79 59 47 01 04 02 04 0b 16 32 08 0c 12 18 24 30 48 60 6c 03 01 01 2d 1a 6e 01 03 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 dd 07 00 50 f2 08 00 00 00 7f 05 00 00 0a 02 01 00 d7 75 eb 1d 7c e1 2f 06 a2 2c a3 df 01 00 67 00 I don't want to track individual user, my goal is to count the number of people in an area. Can I use any other packet type than probe request ? or will there be some similarity in probe request packets originating from same device, that way I can discard the new packet from the same device even if the source address (mac address) is changed.
Informix - Nothing happening when creating a db_space
So Im trying to create a new db_space for my informix database. I already created a file ( /matiasInformixDBSpaces/dbspace_proyectoUTU ) and gave necessary permissions to the informix user and group. Now, logged in as root user I am attempting to create a new db_space. The first one was 500 MB and this one I intended to be 1 GB. the problem I am facing is that when I run the command below, it says "Verifying physical disk space, please wait..." and it just stays there forever. No errors or warnings are thrown. The first time I did it it was super fast. I dont know what is going on now. onspaces -c -d proyectoUTUinformix -p /matiasInformixDBSpaces/dbspace_proyectoUTU -o 5000 -s 1000240 Can someone help me to figure out what is going wrong?
Steps towards diagnosis I’m curious about why you have a non-zero offset. If the name refers to a raw device and the volume manager uses the start, then it makes sense. Otherwise, it is rare to use a non-zero offset. However, that has a negligible effect on speed; it just wastes a little space. Please identify your platform, and the version of Informix you are using. Have you looked at the size of the file from another terminal window? $ a6 timecmd -m -- onspaces -c -d auxilliary -p /opt/informix/dev/$IXS.auxilliary.c0 -o 0 -s 1000240 2018-04-16 22:27:07.348 [PID 71071] onspaces -c -d auxilliary -p /opt/informix/dev/osiris_19.auxilliary.c0 -o 0 -s 1000240 Verifying physical disk space, please wait ... Space successfully added. ** WARNING ** A level 0 archive of Root DBSpace will need to be done. 2018-04-16 22:27:07.969 [PID 71071; status 0x0000] - 0.620s $ I ran the command above on my own Mac (running macOS 10.13.4, with Informix 12.10.FC6 — I need to upgrade!) having created the empty file and set the permissions. This Mac has solid-state disk (SSD). The a6 command runs programs 'as informix'; the timecmd echoes more timing information than the simple time command — start time, command executed, PID, and then finish time, exit status and duration. I use it more for long-running commands, where knowing that it started a couple of hours ago is helpful. Clearly, 0.620s is quick — essentially immediate. It shouldn't take very long on your system — a few seconds at most — to write a file that's 1,024,245,760 bytes long, which is the size of the file I ended up with. So, you need to look hard at the disk you're using. If it's a memory stick, or a remote mounted file system connected via a modem line, then it could take a long time. But a mainstream SSD or spinning disk shouldn't take very long at all. Given what's happened, interrupt the command. Review what's in your online log file — onstat -m for me showed: 05:27:07 Space 'auxilliary' added. 05:30:18 Space 'auxilliary' dropped. I run my servers in UTC time zone; I'm in US/Pacific, currently UTC-7. Hence 22:27 locally corresponds to 05:27 in UTC. Obviously, the 'dropped' message corresponded to my onspaces -d auxilliary command, run about three minutes after the add command. If you can't find a 'space added' message in your online log file, then the operation failed. If you find a 'space added' message, your terminal froze. (You didn't type control-S in it, did you? Try a control-Q to restart it.) You'll need to do the archive mentioned, of course (there's one required after the drop, too) if the space was added. Try using: time dd if=/dev/zero of=/matiasInformixDBSpaces/dbspace_proyectoUTU bs=1024 count=1000240 and see how long that takes. I ran: $ a6 timecmd -m -- dd if=/dev/zero of=/opt/informix/dev/$IXS.auxilliary.c0 bs=1024 count=1000240 2018-04-16 22:43:05.006 [PID 71161] a6 dd 'if=/dev/zero' 'of=/opt/informix/dev/osiris_19.auxilliary.c0' 'bs=1024' 'count=1000240' 1000240+0 records in 1000240+0 records out 1024245760 bytes transferred in 6.740104 secs (151962902 bytes/sec) 2018-04-16 22:43:11.765 [PID 71161; status 0x0000] - 6.758s $ That's much longer than the onspaces command, which means that onspaces did not write to every block in the disk file. When I analyzed the content of the file, I got: $ a6 timecmd -m -- odx $opt/$IXS.auxilliary.c0 2018-04-16 23:10:26.836 [PID 71321] odx /opt/informix/dev/osiris_19.auxilliary.c0 0x0000: 00 00 00 00 04 00 50 35 00 00 00 18 18 00 E4 0F ......P5........ 0x0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ * (253) 0x0FF0: 00 00 00 00 00 00 00 00 00 00 00 00 42 35 16 00 ............B5.. 0x1000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ * (255) 0x2000: 02 00 00 00 04 00 50 35 01 00 08 08 20 00 D8 0F ......P5.... ... 0x2010: 00 00 00 00 00 00 00 00 35 00 00 00 97 D0 03 00 ........5....... 0x2020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ * (252) 0x2FF0: 00 00 00 00 00 00 00 00 18 00 08 00 40 35 16 00 ............#5.. 0x3000: 03 00 00 00 04 00 55 35 00 00 04 08 18 00 E4 0F ......U5........ 0x3010: 00 00 00 00 00 00 00 00 03 00 00 00 00 00 00 00 ................ 0x3020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ * (252) 0x3FF0: 00 00 00 00 00 00 00 00 00 00 00 00 44 35 16 00 ............D5.. 0x4000: 04 00 00 00 04 00 51 35 05 00 02 08 D4 00 14 0F ......Q5........ 0x4010: 00 00 00 00 00 00 00 00 01 00 40 00 01 28 00 00 ..........#..(.. 0x4020: 88 00 00 00 00 00 00 00 01 00 00 10 12 8F D5 5A ...............Z 0x4030: 01 00 00 00 32 00 00 00 32 00 00 00 32 00 00 00 ....2...2...2... 0x4040: 02 00 00 00 00 00 00 00 FF FF FF FF 01 00 40 00 ..............#. 0x4050: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0x4060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0x4070: 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 ................ 0x4080: 01 00 00 00 00 00 00 00 01 00 00 00 0C 00 00 00 ................ 0x4090: 18 00 6D 00 00 00 00 00 00 00 00 00 00 00 00 00 ..m............. 0x40A0: 61 75 78 69 6C 6C 69 61 72 79 00 69 6E 66 6F 72 auxilliary.infor 0x40B0: 6D 69 78 00 54 42 4C 53 70 61 63 65 00 00 00 00 mix.TBLSpace.... 0x40C0: 00 00 00 00 00 04 00 00 00 03 00 00 00 32 00 00 .............2.. 0x40D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ * (240) 0x4FE0: 00 00 00 00 00 00 00 00 C0 00 14 00 C0 00 00 00 ................ 0x4FF0: C0 00 00 00 A0 00 20 00 18 00 88 00 47 35 16 00 ...... .....G5.. 0x5000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ * (64014079) 0x3D0CC000: 2018-04-16 23:10:30.808 [PID 71321; status 0x0000] - 3.971s $ As you can see, some control information was written into the first 0x5000 bytes, but thereafter, the file was all null bytes. I'm not quite sure what it means by 'verifying physical disk space' given that the sub-second timing for onspaces means that it did not actually write to the space. Resolution If you follow the discussion in the comments below, you will see that the cause of the hold up was that the system was in the state CKPT REQ (checkpoint required). This could be seen from onstat output, for example. To get past that, either new logs needed to be added or the logical logs needed to be backed up. Caution: By setting the backup device to /dev/null, you can let the server run without getting blocked, which might be OK while setting up the system, but won't be a good idea in production. Check out the Backup and Restore Guide to learn about ON-BAR and ON-Tape, the two possible backup systems. A lot depends on the context where you'll be running the server. If there's already a system for running backups that uses the BSA interface, using ON-BAR to integrate with that may be most appropriate. If you don't have such a corporate backup system, then ON-Tape may be simpler. Before you go into production, please ensure you have a proper backup strategy, and you have practiced both backups and restores of the system. You need to be confident that your backups work. You need to be confident that you know how to use them. Do make sure your disks are not hard-wired directly to device names. You can use symlinks, or use the names of files. You need to be able to relocate the data, and hard-wired device names can make that difficult.
weird pcap packet length
I am working with pcap in C and comparing the lengths of EAPOL handshakes with those get in wireshark, and the EAPOL packets captured with pcap are longer. The strange thing is that the added length is variable, some days it adds a header of 26 bytes and a footer of 4, making a 185 bytes packet (instead of the 155 byte in wireshark for the first message of the handshake). Some days it adds a 18 byte header with no footer, making a 173 byte packet. When it captures a packet of a certain length, it keeps that format for the whole day and the next day it switches to the other one. I have read this Libpcap File Format but the lengths of those headers don't fill the gap, and wireshark doesn't show Radiotap Headers so I guess I don't have any. The captured packet comes always between the same devices and wireshark returns always the same length. Anyone knows what is going on here? Thanks in advance guys! As requested, I add some examples of the packets captured. For the sake of clarity I will paste only the first message of the handshake, and only for the 185 byte case, as it is the length I get today: As captured by pcap (185 bytes). Extra bytes in bold: 00 00 1a 00 2f 48 00 00 f3 7c 7b 00 00 00 00 00 10 02 85 09 a0 00 db 01 00 0088 02 3a 01 85 74 13 51 b4 a8 d8 b7 b8 17 92 81 d8 b7 b8 17 92 81 00 00 00 00 aa aa 03 00 00 00 88 8e 02 03 00 75 02 00 8a 00 10 00 00 00 00 00 00 00 03 ed 35 bb b6 7d d9 0a 43 ba aa 09 23 f1 f6 6e c9 25 f3 13 c3 91 1c cd ae f5 47 98 0e 6b 15 7a fe 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 16 dd 14 00 0f ac 04 c2 8c 80 68 37 d8 87 fa 37 ab bd 07 1f c3 96 eecb f9 0b 91 The EAPOL packet as shown in Wireshark (155 bytes): 88 02 3a 01 85 74 13 51 b4 a8 d8 b7 b8 17 92 81 d8 b7 b8 17 92 81 00 00 00 00 aa aa 03 00 00 00 88 8e 02 03 00 75 02 00 8a 00 10 00 00 00 00 00 00 00 03 ed 35 bb b6 7d d9 0a 43 ba aa 09 23 f1 f6 6e c9 25 f3 13 c3 91 1c cd ae f5 47 98 0e 6b 15 7a fe 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 16 dd 14 00 0f ac 04 c2 8c 80 68 37 d8 87 fa 37 ab bd 07 1f c3 96 ee
How to copy hex data of captured packet form wireshark
here is the example this is the captured packet data 00000000 00 6e 0b 00 .n.. 00000004 4d 5a e8 00 00 00 00 5b 52 45 55 89 e5 81 c3 81 MZ.....[ REU..... 00000014 12 00 00 ff d3 89 c3 57 68 04 00 00 00 50 ff d0 .......W h....P.. 00000024 68 f0 b5 a2 56 68 05 00 00 00 50 ff d3 00 00 00 h...Vh.. ..P..... 00000034 00 00 00 00 00 00 00 00 00 00 00 00 e0 00 00 00 ........ ........ 00000044 0e 1f ba 0e 00 b4 09 cd 21 b8 01 4c cd 21 54 68 ........ !..L.!Th 00000054 69 73 20 70 72 6f 67 72 61 6d 20 63 61 6e 6e 6f is progr am canno 00000064 74 20 62 65 20 72 75 6e 20 69 6e 20 44 4f 53 20 t be run in DOS 00000074 6d 6f 64 65 2e 0d 0d 0a 24 00 00 00 00 00 00 00 mode.... $....... and i want only the hex part like this 00 6e 0b 00 4d 5a e8 00 00 00 00 5b 52 45 55 89 e5 81 c3 81 12 00 00 ff d3 89 c3 57 68 04 00 00 00 50 ff d0 I try right click on the packet and select copy -> bytes ->hex stream but the hex data I got doesn't look like the above data at all so How Can I copy hex data of captured packet form wireshark ? thanks for reading
On the Wireshark "packet list" panel, right click the packet you want and: 1) if you select Copy->Bytes->Hex stream, you'll get the hex digits as one long string without white spaces 39cb08004528053f000000006f1105faac11745dac11740c039...... 2) if you select Copy->Bytes->Offset Hex, you'll get the hex digits as displayed on the GUI , including the offset of each line starting byte (frame offset) 0010 05 3f 00 00 00 00 6f 11 05 fa ac 11 74 5d ac 11 0020 74 0c 03 9e 03 9d 05 2b 00 00 07 e0 8f ee 8f 1c 0030 ff 00 00 00 00 00 09 0f 00 58 39 cb 60 00 00 00 0040 11 80 08 00 73 00 02 44 00 00 00 00 03 dd de de
You can use TShark. TShark is shipped with Wireshark. Use command: tshark -x -r dns.pcapng frame.number == 10 Output: D:\Wireshark>tshark -r dns.pcapng frame.number == 10 -x 0000 00 25 9c ca 94 fe 90 e6 ba 71 70 03 08 00 45 00 .%.......qp...E. 0010 00 3f 6d 61 00 00 80 11 7d dc 0a 01 01 0a 11 22 .?ma....}......" 0020 33 44 f0 1d 00 35 00 2b be 3e 71 dd 01 00 00 01 3D...5.+.>q..... 0030 00 00 00 00 00 00 0d 73 74 61 63 6b 6f 76 65 72 .......stackover 0040 66 6c 6f 77 03 63 6f 6d 00 00 ff 00 01 flow.com..... Copy and paste the hex part. Hope this helps
If there are several packets you're interested in, you can export them to a file. mark those packets (right click on each packet then Mark Packet (toggle) or Ctrl + M) choose File > Export > File.... Make sure you select Marked packets. if you're only interested in the hex data, make sure only Packet Bytes is checked in Packet Format Note that when exporting you also have the choice with First to last marked as well as Range, if the interesting packets are next to each other.