I'm using tshark with tls.keylog_file option to decrypt my websocket TLS stream. After I run it through tshark, I get a layer 'DATA-TEXT-LINES' which contains the decrypted data. However, this data seems truncated, as I see through the wireshark GUI which has the full decrypted data. I searched through the forums where someone suggested changing ITEM_LABEL_LENGTH in epan/proto.h . So I did that and rebuilt from source, however that also doesn't seem to help.
Any help would be appreciated. I'm using version 3.6.5
Related
I am not familiar with influxdb command line especially influxDB2.0. so I choose to use InfluxDB 8086 port frontend. but I found if want to download .csv by frontend, too many data leads to browser collapse, which at last leads to download failure.
I have read influxdb2.0 documentation and found no answer. Whether I must use command line or what command line should I use? Thanks a lot in advance
I have the same issues using Flux in a browser session.
If you need a lot of data use the Influx API and catch the result in a file. See the 'example query request' using curl on the referenced page. I find this to be very quick and haven't had it overload from returning large data sets.
(If the amount of data is enormous you can also ask Influx to gzip it before download, but of course this may load up the machine it's running on.)
I am using tshark to output the human-readable text from TCP packets. I do this with the data.text field. For example, my tshark.exe switches include:
-o data.show_as_text:TRUE -T fields -e data.text
This works just fine for most packets. The trouble comes when a packet is retransmitted by the sender. In these cases, data.text is always blank.
When analyzing the traffic in Wireshark, I see that retransmitted TCP frames (these are labeled as [TCP Retransmission] and include the note "This frame is a (suspected) retransmission") do not include the Data field at all - Wireshark does not reconstruct it (even though I have the parse data as text option enabled). Instead, these frames have a "Retransmitted TCP segment data" field (tcp.segment_data) which does not include any parsed text.
Is this a bug with tshark/wireshark? Why is the Data field not being constructed for these packets? Is there some other way for me to get the text from retransmitted TCP packets, or is my only option to manually decode the hex of tcp.segment_data for retransmitted packets?
The TCP connection I am monitoring frequently has retransmitted packets, so I am missing critical data at the moment.
Do you have TCP reassembly enabled? Maybe try to disable it with -o tcp.desegment_tcp_streams:FALSE? If that doesn't help, maybe there's a bug with the version of Wireshark you're using. You could try upgrading to the latest stable version (2.6.1 as of this writing) and try again. You could even try a recent automated installer, if one is available for your OS or you could try building Wireshark from sources. If the problem still persists, you could file a Wireshark bug report along with a sample capture file to illustrate the problem.
You may also want to add a Wireshark display filter to your command-line to limit the output to only those packets that contain data.text, e.g. -Y data.text.
Refer to the tshark man page for more information about the -Y and other options.
We need to protect customer data and using FirebirdSQL 2.5(.8) with Delphi 7.
Also it is essential to do regular backups on "secondary" PC, or pen-drives if the "master" fails.
For that we used this method, calling Gbak.exe and 7z.exe with stdin/out.
Realized that was a bad idea because it's very easy to see the parameters (passwords) added to command line during the process, even with a simple Task-manager.
Is there a more secure way to do it?
(Using standard Interbase componenst OR UIB)
Upgrade to Firebird 3 which added Database Encryption capability. If you don't want or cannot, I believe you might run the GBAK tool from your application with the STDOUT option but instead of using 7-zip for compression you would read that output in your application, and encrypt such input by some encryption library on the fly.
I believe you may find many examples how to run an application and read its standard output over here (here is something related to start with), so the rest might be about finding a way of an on the fly stream encryption. Or just capturing STDOUT in one stream and encypting in another.
Firebird guys on SQL.ru forum say, that actually it is possible to use Services API to get backup stream remotely.
That does not mean that IBX or UIB or any other library readily support it though. Maybe it does, maybe not.
They suggested to read Release Notes for Firebird 2.5.2 or Part 4 of doc\README.services_extension.txt files of Firebird 2.5.2+ installation.
Below is a small excerpt from the latter:
The simplest way to use this feature is fbsvcmgr. To backup database
run approximately the following:
fbsvcmgr remotehost:service_mgr -user sysdba -password XXX action_backup -dbname some.fdb -bkp_file stdout >some.fbk
and to restore it:
fbsvcmgr remotehost:service_mgr -user sysdba -password XXX action_restore -dbname some.fdb -bkp_file stdin <some.fbk
Please notice - you can't use "verbose" switch when performing backup
because data channel from server to client is used to deliver blocks
of fbk files. You will get appropriate error message if you try to do
it. When restoring database verbose mode may be used without
limitations.
If you want to perform backup/restore from your own program, you
should use services API for it. Backup is very simple - just pass
"stdout" as backup file name to server and use isc_info_svc_to_eof in
isc_service_query() call. Data, returned by repeating calls to
isc_service_query() (certainly with isc_info_svc_to_eof tag) is a
stream, representing image of backup file.
Restore is a bit more tricky. Client sends new spb parameter
isc_info_svc_stdin to server in
isc_service_query(). If service needs some data in stdin, it returns
isc_info_svc_stdin in query results, followed by 4-bytes value -
number of bytes server is ready to accept from client. (0 value means
no more data is needed right now.) The main trick is that client
should NOT send more data than requested by server - this causes an
error "Size of data is more than requested". The data is sent in next
isc_service_query() call in the send_items block, using
isc_info_svc_line tag in traditional form: isc_info_svc_line, 2 bytes
length, data. When the server needs next portion, it once more returns
non-zero isc_info_svc_stdin value from isc_service_query().
A sample of how services API should be used for remote backup and
restore can be found in source code of fbsvcmgr.
I am a newbie of the Contiki System. I am trying to upload binary data (in
txt. format, it is some recorded interference) to the TelosB node to regenerate
interference (the data file is in large size, 5M for example), in other words, I am trying to use Contiki to read binary files and send to the node. I googled
this problem, but did not found much useful information.
Could anyone give me some idea?
Thank you in advance.
The easiest way to send data from/to your TelosB is to just send it to the tty associated with the USB port it's connected to (e.g., /dev/ttyUSB0). Your TelosB will be able to simply read the data from stdin (and vice versa).
I need to make tcpdump using wireshark or tcpdump
For some tcp streams in log I need full packet info.
But for tcp streams in log I need to remove all info except full uri info.
For this I'am going to use regular expressions.
If URI, http.request or http.response match some of regular expressions
then I need to store full tcp stream info.
If doesn't match --- then I need to remove all tcp stream info except full uri info.
I need it to reduce log size.
What tool do you advise for this ?
Or may be some php/python library will be helpful to create script that will filter log ?
tcpick and tcpxtract are two tools available to filter and extract information from a tcpdump file. They are both open-source and available at sourceforge.net. You will have to write your own routine for how and what information you would like to extract. tcpick is fairly flexible regarding what parts of a packet you can view/extract.
I use TraceWrangler in my projects, which despite being beta, works very well. It allows, in addition to editing the L2/L3 headers, to sanitize the packets.