Re: [Wireshark-dev] Its possible to build and run wireshark from IDE
Hello Tomer,
W dniu 2018-11-08 10:46, Guy Harris napisał(a):
On Nov 8, 2018, at 12:52 AM, Dario Lombardo wrote:
On Wed, Nov 7, 2018 at 5:39 PM Tomer Bar
wrote:
i want to expose the validation of the display filter and use it like
service?
any idea?
Do you want to do it programmatically (I mean you have a C code and
you want to link with wireshark in some way) or can you do it running
binary tshark?
If the latter, you can run "tshark -Y FILTER" and check the return
code. 2 means error in the filter. You need something more that that,
but it may be a starting point.
Or use "dftest FILTER" - redirect its standard output and error to the
null device (/dev/null on UN*X or NUL: on Windows), and check the exit
status - again, 2 is an error, 0 is no error:
(...)
if you would like to have JSON output instead you can use sharkd:
$ echo '{"req":"check","filter":"ip.addr == 127.0.0.1"}' |
build/run/sharkd - 2>/dev/null
{"err":0,"filter":"ok"}
for HTTP service you can use demo.webshark.io:
$ wget -q -O -
'http://demo.webshark.io/webshark/json?req=check&filter=ip.addr !=
127.0.0.1'; echo
{"err":0,"filter":"warn"}
filter JSON key can be also like:
{"err":0,"filter":"\"foobar\" is not a valid hostname or IPv4
address."}
___
Sent via:Wireshark-dev mailing list
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Why are ett[] arrays static?
W dniu 2018-10-19 16:51, Jeff Morriss napisał(a):
Is it just me or is there no reason for ett[] arrays:
/* Setup protocol subtree array */
static gint *ett[] = {
&ett_PROTOABBREV
to be static?
It seems to me that making it static is just wasting space (keeping the
array around forever)?
If you make it not static, it will waste memory and CPU by having &
running code to initialize this array.
My compiler (gcc 7.3.0-16ubuntu3) with >= 32 etts, after removing static
makes array in .data, but copies it during function execution.
___
Sent via:Wireshark-dev mailing list
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] tools/check[hf|APIs|filtername].pl need updating?
Hi, W dniu 2018-09-18 16:56, Maynard, Chris napisał(a): While investigating the transum-related crash, I had suspected some unregistered hf's and ran the various tools like checkhf.pl. I then noticed that a number of dissectors seemed to have changed a bit from what I was used to before (...) These changes are quite old. For udp I did it in Aug 2013 (88eaebaedf2e19c493ea696f633463e4f2a9a757). some wireshark-dev threads: - https://www.wireshark.org/lists/wireshark-dev/201307/msg00222.html - thread continuation: https://www.wireshark.org/lists/wireshark-dev/201308/msg00035.html Nobody stopped me that time. And I guess I missed the reasoning behind the restructuring, but what is the purpose/benefit of this restructuring To sum up: Restructuring idea was to remove usage of int hf_foo, so you would need only to declare header_field_info hfi_foo (unfortunate, you still need to do it on top of file). Benefit is no more ints, so: - proto_tree_ api checks if you passed header_field_info structure, - You don't need to declare int hf_foo = -1; (bonus: binary size smaller 4 bytes per hf), - no need for table lookup in proto_tree_add_* and use of HAVE_HFI_SECTION_INIT? Idea was that HFI_INIT(proto_bar) would put all protocol hfi's into single binary section. This way wireshark could auto-register these fields without need of some indirect array (bonus: binary size smaller by sizeof(void *) per hfi). After 5 years simple grep shows that only 36 dissectors are using NEW_PROTO_TREE_API, so it seems that this API is not well known or not liked. If it makes problem I would suggest to drop it. Alexis suggested the same in 2015: https://www.wireshark.org/lists/wireshark-dev/201508/msg00087.html Jakub. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Dealing with aggregated packets
Hello, W dniu 2018-07-02 22:33, Jeff Morriss napisał(a): It's an idea that's been tossed around since at least 2006[1]. Someone (Jakub?) had played around with it but eventually gave up; unfortunately I can't find the reference to that. It seems I did one in 2012, https://www.wireshark.org/lists/wireshark-dev/201208/msg00200.html patchset: https://www.wireshark.org/~darkjames/multicols/ screenshot: https://www.wireshark.org/~darkjames/protocolstack.png looking in 0004 patch, the idea was that every protocol, (or PDU) would call pinfo->cinfo = add_new_column_set(pinfo, TRUE); which would create new (sub)row in column list. [1] https://www.wireshark.org/lists/wireshark-dev/200606/msg00147.html I think the UI presentation is one thing but the next (and equally important IMO) thing is how the filtering will work. I am no longer reviewing changes actively, but as far as I know we don't have filtering for columns? Do we? Jakub. On Mon, Jul 2, 2018 at 4:05 PM, Roland Knall wrote: This is a feature, that has been discussed on/off for a longer time now. I think, this mockup is by far the best I've seen so far. You have my vote for implementing it, and I think it will be a big improvement. cheers Roland Am Mo., 2. Juli 2018 um 21:19 Uhr schrieb Darien Spencer >: Hey devs There's something that has been bothering me in my wireshark experience and I wanted to bring to discussion *Some protocols can aggregate several payloads *such as *SCTP and TCP* Viewing those in wireshark could be difficult if many payloads are present. Specificly *the Info column gets long quickly *(assuming fences are used) Here is an example - the info column of a SCTP packet with 6 payloads: https://i.imgur.com/GeA2WmU.png It can be challenging to spot a specific packets in those overpopulated info columns further more, once you find the right packet by the info column you are served with your next challenge - finding which of the aggregated packets in the protocol tree is the one you are looking for. I was thinking about introducing a newer concept to wireshark in the form of *"sub-packets"* Maybe that's a cosmetic feature to add to the Qt GUI and maybe it required some changes to the dissection engine. I'm not familiar enought with the GUI to tell. What I had in mind is an option to 'expend' a packet in the main view so its aggregated sub packets are seen in a tree under it Here's a mock hoping it's get the idea across: https://i.imgur.com/WfSvg6x.png I can imagine how this might require a change to the way info is saved in the dissectors. Does anyone else feel this is an issue when analysing traffic? Is this a feature fitting the GUI/User experience guidelines of wireshark? Cheers, Darien ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] compilation hangs on Ubuntu
Hello,
W dniu 2018-05-13 17:15, Eugène Adell napisał(a):
I'm facing a problem on my development server (Ubuntu 16.04 hosted on
VMWARE) when trying to compile Wireshark. It was working with older
versions (2.0 for example), but now it's like the compilation will
never
end.
I installed/updated all the required packages, since version 2.6 seems
quite different.
I'm doing an strace -f -o to find out what could be wrong, but no clue.
The
strace log being too big, here is how it looks like :
1900 execve("/usr/bin/cmake", ["cmake", "-LH", "../wireshark"], [/*
22 vars */]) = 0
[cut]
thousands of lines such as :
1901 open("/proc/537/status", O_RDONLY) = -1 ENOENT (No such file or
directory)
1901 open("/proc/538/status", O_RDONLY) = -1 ENOENT (No such file or
directory)
1901 open("/proc/539/status", O_RDONLY) = -1 ENOENT (No such file or
directory)
1901 open("/proc/540/status", O_RDONLY) = -1 ENOENT (No such file or
directory)
1901 open("/proc/541/status", O_RDONLY) = -1 ENOENT (No such file or
directory)
1901 open("/proc/542/status", O_RDONLY) = -1 ENOENT (No such file or
directory)
1901 open("/proc/543/status", O_RDONLY) = -1 ENOENT (No such file or
directory)
1901 open("/proc/544/status", O_RDONLY) = -1 ENOENT (No such file or
directory)
then thousands and thousands of lines such as the following, and it
seems
it will never end :
1901 open("/proc/882/status", O_RDONLY) = 3
1901 fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
1901 read(3, "Name:\tvmhgfs-fuse\nUmask:\t\nSt"..., 1024) = 1024
1901 read(3, ",,,,"..., 1024) = 263
1901 read(3, "", 1024) = 0
1901 close(3) = 0
1901 open("/proc/965/status", O_RDONLY) = 3
1901 fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
1901 read(3, "Name:\tsystemd-logind\nUmask:\t0022"..., 1024) = 1024
1901 read(3, "000,,,00"..., 1024) = 269
1901 read(3, "", 1024) = 0
1901 close(3) = 0
1901 open("/proc/968/status", O_RDONLY) = 3
1901 fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
1901 read(3, "Name:\tdbus-daemon\nUmask:\t0022\nSt"..., 1024) = 1024
1901 read(3, "00,,,,00"..., 1024) = 283
1901 read(3, "", 1024) = 0
1901 close(3) = 0
How can I resolve this ?
Not sure, but it seems that first subprocess (1901 == 1900 + 1) makes
some strange things.
Looking on my strace output of cmake -LH ../wireshark:
6410 execve("/usr/bin/cmake", ["cmake", "-LH", "../wireshark/"],
0x7ffe72092520 /* 32 vars */) = 0
(..)
6410 clone(child_stack=NULL,
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0x7f7cde41ba50) = 6411
6411 execve("/usr/bin/python", ["/usr/bin/python", "-c", "import sys;
sys.stdout.write(';'.join([str(x) for x in sys.version_info[:3]]))"],
0x7ffc7adb4958 /* 32 vars */) = 0
first execve() is /usr/bin/python -c "import sys;
sys.stdout.write(';'.join([str(x) for x in sys.version_info[:3]]))"
Is it same for you? If you run from same shell:
/usr/bin/python -c "import sys; sys.stdout.write(';'.join([str(x) for
x in sys.version_info[:3]]))"
does it hang?
Could you please attach gzip compressed strace log?
Kind Regards,
Jakub.
___
Sent via:Wireshark-dev mailing list
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] register_tap_listener memleak
W dniu 2018-03-15 13:24, Peter Wu napisał(a): > I was looking at memleaks as reported by LSAN while running the > decryption test suite, there are quite a number of occurrences. Can register_tap_listener() return enum code (one of: success, not found, wrong filter)? You will get rid of memleak, and users will get nicely translated message error. That sounds like a great idea at first, but it seems not viable given that the error messages are: - "Tap not found" is passed by caller, so caller should be able to show it in message error. - "Filter "" is invalid - " Ah, I only did notice which is also passed by caller, didn't notice dfilter_compile_error thing :( Would it be to big change to pass compiled dfilter to register_tap_listener()? ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] register_tap_listener memleak
Hi Peter, W dniu 2018-03-15 13:24, Peter Wu napisał(a): I was looking at memleaks as reported by LSAN while running the decryption test suite, there are quite a number of occurrences. One of them is tap (return value of register_tap_listener) which is a GString which seems unnecessary since it is an error message which the caller should not have to modify. Dario tried to convert that to a gchar before in https://code.wireshark.org/review/15270 but that particular patch was reverted in v2.1.1rc0-197-ga383e692c8. Pascal tried again in https://code.wireshark.org/review/16053, but somehow it also got stuck. Before trying to touch this again, is there something to be aware of? I just want to modify register_tap_listener: - Change GString to char * - Either use NULL wmem scope or use g_strdup_printf. - Add G_GNUC_WARN_UNUSED_RESULT such that callers will not accidentally leak any error messages. - Modify callers such that they do check the error. (g_warning?) Can register_tap_listener() return enum code (one of: success, not found, wrong filter)? You will get rid of memleak, and users will get nicely translated message error. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] 2.5.0, 2.6, and 3.0 release planning
Hello, W dniu 2018-02-02 23:45, Gerald Combs napisał(a): I think we've fixed the major issues identified by Stig, Jim, and others so I'd like to release 2.5.0 on February 6. In oss-fuzz queue currently there are few crashes, and one inifite loop. Should it be a blocker for a release? Regards, Jakub. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Windows 64-bit petri-dish build timing out?
Hello Martin, W dniu 2017-12-09 14:52, Martin Mathieson via Wireshark-dev napisał(a): There have been some failures recently, e.g. https://buildbot.wireshark.org/petri-dish/builders/Windows%20Petri%20Dish%20x64/builds/1123/steps/compile_1/logs/stdio That build took over 21 minutes, and near the start of the log you can see: in dir C:\buildbot\builders\windows-x86-64-petri-dish\windows-x86-64-petri-dish\build/cmbuild (timeout 1200 secs) Not sure about timeout, but recent cause of windows build failures was missing declaration of packet_range_t in file_dlg_win32.h From your log: filter_autocomplete.c 130>C:\buildbot\builders\windows-x86-64-petri-dish\windows-x86-64-petri-dish\build\ui/win32/file_dlg_win32.h(73): error C2143: syntax error: missing ')' before '*' (compiling source file C:\buildbot\builders\windows-x86-64-petri-dish\windows-x86-64-petri-dish\build\ui\gtk\export_sslkeys.c) [C:\buildbot\builders\windows-x86-64-petri-dish\windows-x86-64-petri-dish\build\cmbuild\ui\gtk\gtkui.vcxproj] 130>C:\buildbot\builders\windows-x86-64-petri-dish\windows-x86-64-petri-dish\build\ui/win32/file_dlg_win32.h(73): error C2081: 'packet_range_t': name in formal parameter list illegal (compiling source file C:\buildbot\builders\windows-x86-64-petri-dish\windows-x86-64-petri-dish\build\ui\gtk\export_sslkeys.c) [C:\buildbot\builders\windows-x86-64-petri-dish\windows-x86-64-petri-dish\build\cmbuild\ui\gtk\gtkui.vcxproj] it seems to be fixed by 2cee4f432feddc5deb48154a97fcb63823b4e6b4. Windows Server 2016 x64 buildbot[1] confirm this: #1193 f29b3deb6d867b16fb8bc4bd5f66a5b6326a6727 OK #1194 8aa14236f8b0ea69901ea9ed87ebabd0d278e973 FAIL #1195 5d6315fefe6f2ffb1cafb3ad12522a57b43876ba FAIL #1196 2cee4f432feddc5deb48154a97fcb63823b4e6b4 OK [1] https://buildbot.wireshark.org/wireshark-master/builders/Windows%20Server%202016%20x64 Regards, Jakub. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Qt-related error during build prep
Hello Paul, W dniu 2017-12-03 18:39, Paul Offord napisał(a): I setup the environment with: (cut) set QT5_BASE_DIR=QT5_BASE_DIR=C:\Qt\5.9.3\msvc2015_64 Please try: QT5_BASE_DIR=C:\Qt\5.9.3\msvc2015_64 ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Processing packet before exporting it.
W dniu 2017-11-22 18:02, Pascal Quantin napisał(a): There was indeed an experimental packet editor, but it was very limited (basically as far as I can remember it could edit values like what you could do with an hex editor, but was not a generic encoder for any given protocol). It was a little bit smarter hex editor :) It could detect wireshark data types, like: big/little numbers with bitmasks; strings; IP addresses, ... There is a demo on youtube editing string and checksum: https://www.youtube.com/watch?time_continue=93&v=DcQHE6Z3Ghc Regards, Jakub. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Can't compile wireshark with gcc 6.3 and musl (Alpine Linux)
Hello Adam,
W dniu 2017-09-25 07:05, Adam Baxter napisał(a):
It's failing on extcap.
make[2]: Entering directory '/wireshark/extcap'
(...)
CC udpdump.o
udpdump.c: In function 'setup_listener':
udpdump.c:126:9: error: variable 'timeout' has initializer but
incomplete
type
struct timeval timeout = { 1, 0 };
Thanks for reporting, missing timeval definition is now fixed by
https://code.wireshark.org/review/23728/
The Dockerfile I'm using for this build is as follows:
FROM alpine:latest
MAINTAINER Adam Baxter
RUN apk --update add git
RUN git clone --depth=1 https://github.com/wireshark/wireshark
RUN apk add gcc libc-dev make libtool autoconf automake python
pkgconfig bison flex
RUN apk add libgcrypt-dev glib-dev libpcap-dev c-ares-dev
RUN cd wireshark && ./autogen.sh
RUN cd wireshark && ./configure --disable-wireshark
--without-plugins--enable-static
RUN cd wireshark && make -j8
I can compile wireshark if I clone from official repository:
RUN git clone --depth=1 https://code.wireshark.org/review/wireshark
and if I compile shared version:
RUN cd wireshark && CFLAGS="-O0 -pipe" ./configure --disable-wireshark
--without-plugins
I'd still like to know how to disable / fix the warnings-as-errors.
Missing definition is an error, not warning.
In future you can disable warnings-as-errors with: ./configure
--disable-warnings-as-errors
Kind regards,
Jakub.
___
Sent via:Wireshark-dev mailing list
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] External processes in Snort dissector - code execution
Hi Peter, W dniu 2017-08-28 18:50, Peter Wu napisał(a): This can especially problematic for services like Cloudshark and Webshark (by Jakub). The former is not yet affected since it does not use 2.4 code (yet?) but the latter seems theoretically vulnerable as it has a setconf API function (I was not able to get it to work though as setconf changes are not visible in dumpconf). dumpconf now support dumping value of snort.binary (https://code.wireshark.org/review/23268/), and sharkd setconf requested is blocked from webshark API (https://bitbucket.org/jwzawadzki/webshark/commits/2687eec6b0413462e072a660af96896ee7cd6c33). Thanks, Jakub. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Compilation error Red Hat 3.4.3-9.EL4
Hello,
W dniu 2017-06-27 05:33, Guy Harris napisał(a):
On Apr 29, 2011, at 12:52 AM, Jakub Zawadzki
wrote:
On Thu, Apr 28, 2011 at 11:24:08PM -0700, Guy Harris wrote:
I wouldn't to it by checking for a particular version, though -
I'd just check for inflatePrime() and, if it's not present, don't
build in the "transparent access to gzipped files" support.
Actually we still can do transparent access, but only when BLOCK is
not inside
middle of byte.
So does that mean "we can still do transparent access, but it won't
work with some valid gzipped files", or does it mean "we can still do
transparent access on all valid gzipped files as long as the code is
careful", or does it mean "we can still do transparent access on all
valid gzipped files, but it won't be as efficient as it would be with
inflatePrime()"?
Given that the random-access-to-gzipped-files code is compiled in
regardless of whether we have inflatePrime(), presumably it doesn't
mean the first of those.
I would say that mix of (1) and (3).
It all depends what's position of blocks in compressed file (we don't
have control on it),
attaching sample code for checking.
I think it's possible to craft gzipped capture file where block always
finish in middle of byte.
Jakub./* file_wrappers.c
*
* Wiretap Library
* Copyright (c) 1998 by Gilbert Ramirez
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
* of the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
*/
/* file_access interface based heavily on zlib gzread.c and gzlib.c from zlib
* Copyright (C) 1995-2010 Jean-loup Gailly and Mark Adler
* under licence:
*
* This software is provided 'as-is', without any express or implied
* warranty. In no event will the authors be held liable for any damages
* arising from the use of this software.
*
* Permission is granted to anyone to use this software for any purpose,
* including commercial applications, and to alter it and redistribute it
* freely, subject to the following restrictions:
*
* 1. The origin of this software must not be misrepresented; you must not
* claim that you wrote the original software. If you use this software
* in a product, an acknowledgment in the product documentation would be
* appreciated but is not required.
* 2. Altered source versions must be plainly marked as such, and must not be
* misrepresented as being the original software.
* 3. This notice may not be removed or altered from any source distribution.
*/
#include
#include
#include
#include
#include
#include
#include
#include
#define WTAP_ERR_SHORT_READ -1
#define WTAP_ERR_DECOMPRESS -2
#define ZLIB_CONST
#include
typedef struct wtap_reader *FILE_T;
/* values for wtap_reader compression */
typedef enum {
UNKNOWN, /* unknown - look for a gzip header */
UNCOMPRESSED, /* uncompressed - copy input directly */
ZLIB, /* decompress a zlib stream */
GZIP_AFTER_HEADER
} compression_t;
struct wtap_reader {
int fd;/* file descriptor */
int64_t raw_pos;/* current position in file (just to not call lseek()) */
int64_t pos;/* current position in uncompressed data */
unsigned int size;/* buffer size */
unsigned char *in; /* input buffer */
unsigned char *out;/* output buffer (double-sized when reading) */
unsigned char *next; /* next output data to deliver or write */
unsigned int have;/* amount of output data unused at next */
int eof; /* TRUE if end of input file reached */
int64_t raw;/* where the raw data started, for seeking */
compression_t compression; /* type of compression, if any */
/* error information */
int err; /* error code */
unsigned int avail_in;/* number of bytes available at next_in */
unsigned char *next_in;/* next input byte */
/* zlib inflate stream */
z_stream strm; /* stream structure in-place (not a pointer) */
};
static int /* gz_load */
raw_read(FILE_T state, unsigned char *buf, unsigned int count, unsigned int *have)
{
ssize_t ret;
*have = 0;
do {
ret = read(state->f
Re: [Wireshark-dev] Remote Control Plugin - Can I submit to the Wireshark project
Hello, W dniu 2017-01-08 15:30, Alexis La Goutte napisał(a): for disable when code will be review, we can help you to add this "feature" About sharkd for me, it is different because sharkd is for a web wireshark (like CloudShark) If this will get some "merge points" for sharkd, it's my main use cases, still you can use sharkd: - in most cases instead of running tshark with pdml output, - to get some report/statistic (TAPs) about pcap, and to not parse tshark output. Still, sharkd is NOT for remote controlling neither Qt, nor GTK wireshark GUI. It could be used to remotely control webshark UI, but I believe such code should actually go to web appplication, and not sharkd. To sum up sharkd is definitely not what Paul need. Cheers, Jakub. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] How to get a header_field_info instance from its id?
Hi,
W dniu 19.08.2015 16:45, yves baumes napisał(a):
My first one would be: how do I get the header_field_info structure
instance from its structure id? Here is what I'm trying to achieve:
static int hf_instr_id = -1;
[...]
{ &hf_instr_id,
{ "Instrument Identifier", "my_proto.instr_id", FT_UINT64,
BASE_DEC, NULL, 0x00,
"[...]", HFILL }
},
[...]
ptvcursor_add(cursor, hf_instr_id, 8, ENC_LITTLE_ENDIAN);
In the line just above I'd like to replace the length (which is 8) by
something roughly looking like that:
int len = ftype_len(gap_hfinfo.hfi[xxx]->type);
ptvcursor_add(cursor, hf_instr_id, len, ENC_LITTLE_ENDIAN);
One of my issue is that gap_hfinfo array (which contains all the
header_fields_info instances) is static to the proto.c file. And I
find no accessors to it.
Is there an actual way that I've overlooked?
/** Get the header_field information based upon a field or protocol id.
@param hfindex item # n (0-indexed)
@return the registered item */
WS_DLL_PUBLIC header_field_info* proto_registrar_get_nth(guint hfindex);
btw. there is also a proto_registrar_get_length() function,
which do what you want (ftype_len(...)->type).
Cheers,
Jakub.
___
Sent via:Wireshark-dev mailing list
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] tvb allocator (was: Re: [Wireshark-commits] master b6d20a2: Optimize reseting epan_dissect_t when filtering.)
Hi, On Sat, Jun 21, 2014 at 10:12:48PM +0200, Jakub Zawadzki wrote: > If we're in topic of optimizing 'slower' [de]allocations in common functions: > > - tvb allocation/deallocation (2.5%, or 3.4% when no filtering) > >243,931,671 * ???:tvb_new > [/tmp/wireshark/epan/.libs/libwireshark.so.0.0.0] >202,052,290 > ???:g_slice_alloc (2463493x) > [/usr/lib64/libglib-2.0.so.0.3600.4] > >291,765,126 * ???:tvb_free_chain > [/tmp/wireshark/epan/.libs/libwireshark.so.0.0.0] >256,390,635 > ???:g_slice_free1 (2435843x) > [/usr/lib64/libglib-2.0.so.0.3600.4] > This, or next week I'll try to do tvb. ... or maybe this week: ver0 | 18,055,719,820 (---) | Base version 96f0585268f1cc4e820767c4038c10ed4915c12a ver1 | 18,185,185,838 (0.6% slower) | Change tvb allocator g_slice_* to wmem with file scope ver2 | 17,809,433,204 (1.4% faster) | Change tvb allocator g_slice_* to wmem with file/packet scope ver3 | 17,812,128,887 (1.3% faster) | Change tvb allocator g_slice_* to simple object allocator with epan scope ver4 | 17,704,132,561 (2.0% faster) | Change tvb allocator g_slice_* to simple object allocator with file scope I have uploaded patches & profiler outputs to: http://www.wireshark.org/~darkjames/tvb-opt-allocator/ Please review, and check what version is OK to be applied. P.S: I'll might find some time to do ver5 with slab allocator, but it'll look like object allocator API with epan scope. Cheers, Jakub. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] un-encrypted traffic over port 443
Hi, On Sun, Jun 29, 2014 at 01:43:39PM +0200, Toralf Förster wrote: > > /mew wonders if wireshark should print a warning if a http traffic goes > over port 443 (eg a TRAC temporarily configured at that port instead of > 80) but is not encrypted, currently those packets are marked as "SSL" > but they aren't secure. Could you try if enabling 'tcp.try_heuristic_first' option, does dissect packet as http? Cheers, Jakub. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] master 9079e3a: Cheat and try to fix the generated file manually.
Hello Evan, On Mon, Jun 23, 2014 at 02:10:13PM -0400, Evan Huus wrote: > Storing generated files in source control makes maintenance and patch > review much harder and puts extra requirements on us to keep things in > sync. I'd rather the computer do the extra work :) But in the same time, we can have 3rd party library, like nghttp2[1] (12KLOC) put into git. This is already more than 30 commits behind nghttp2/lib git HEAD, nor README.nghttp2 is updated about recent fixes in this forked code. > We store C files and require a compiler, where we could just store the > compiled .o files in source control. To me this is much the same thing. Great to know. > Balint and Jörg and I discussed that we would eventually like to remove the > ASN.1 generated source from git as well, and make that a standard part of > the build process. I am happy to hear this, please do. For sure you want also do this for X11 dissector, which for rebuilt only requires downloading mesa sources. BR, Jakub. [1] I am very sorry Alexis, but I haven't found better example. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Stateless Dissection
On Sun, Jun 22, 2014 at 05:45:45PM -0400, Evan Huus wrote: > On Sun, Jun 22, 2014 at 5:25 PM, Jakub Zawadzki > wrote: > > > On Sun, Jun 22, 2014 at 05:07:19PM -0400, Evan Huus wrote: > > > The implementation is a bit of a hack in that stateless dissection still > > > does all the stateful work, it just throws it away after each packet (so > > > stateless is actually slightly slower than stateful) but it seems to work > > > in my simple tests. > > > > Great, but I'd like to see also something working for *given* frame number, > > this would also fix issues with -R (like remove all conversations, > > reassemblies created by *given* frame number). > > I don't think I understand? If you have the -R "somefilter" and later you drop this frame, frame number will be reused by next one, and this really confuses the libwireshark. It'd be really nice to have posibility to 'undo' operations done after dissecting current frame. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Stateless Dissection
Hi Evan, On Sun, Jun 22, 2014 at 05:07:19PM -0400, Evan Huus wrote: > The implementation is a bit of a hack in that stateless dissection still > does all the stateful work, it just throws it away after each packet (so > stateless is actually slightly slower than stateful) but it seems to work > in my simple tests. > > Does this seem useful to people? Ideas for a better flag (Z just happened > to be handy)? Other thoughts, comments, suggestions? Great, but I'd like to see also something working for *given* frame number, this would also fix issues with -R (like remove all conversations, reassemblies created by *given* frame number). About flag, I'd suggest -0 (zero-pass) ;-) Cheers, Jakub ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] master b6d20a2: Optimize reseting epan_dissect_t when filtering.
Hi Evan, On Thu, Jun 19, 2014 at 04:40:06PM -0700, Evan Huus wrote: > On Thu, Jun 19, 2014 at 4:33 PM, Wireshark code review > wrote: > > > URL: > > https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=b6d20a27a149c1b09f17561f972d0f45a41de992 > > Submitter: Anders Broman (a.broma...@gmail.com) > > Changed: branch: master > > Repository: wireshark > > > > Commits: > > > > b6d20a2 by Jakub Zawadzki (darkja...@darkjames.pl): > > > > Optimize reseting epan_dissect_t when filtering. > > > > Don't destroy interesting_hfids hash table, just remove all values. > > > > [cut] > > Another possible improvement, rather than g_mallocing the elements in the > hash table, we could put them in the pinfo pool, which is always freed when > proto_tree_reset or proto_tree_free are called... Sure, we can do it, but it looks for me < 1%. 18,116,612,393 PROGRAM TOTALS wmem might reduce *a little* this 93M Ir below: 266,173,051 * ???:proto_tree_add_node [/tmp/wireshark/epan/.libs/libwireshark.so.0.0.0] 63,201,727 > ???:g_ptr_array_add (291740x) [/usr/lib64/libglib-2.0.so.0.3600.4] 30,049,112 > ???:g_ptr_array_new (291740x) [/usr/lib64/libglib-2.0.so.0.3600.4] + we will get rid of 74M Ir. 79,962,317 * ???:free_GPtrArray_value [/tmp/wireshark/epan/.libs/libwireshark.so.0.0.0] 74,419,257 > ???:g_ptr_array_free (291740x) [/usr/lib64/libglib-2.0.so.0.3600.4] For now I'm not optimizating anything which gives < 1%, but I think Anders will be grateful for any optimizations. If we're in topic of optimizing 'slower' [de]allocations in common functions: - tvb allocation/deallocation (2.5%, or 3.4% when no filtering) 243,931,671 * ???:tvb_new [/tmp/wireshark/epan/.libs/libwireshark.so.0.0.0] 202,052,290 > ???:g_slice_alloc (2463493x) [/usr/lib64/libglib-2.0.so.0.3600.4] 291,765,126 * ???:tvb_free_chain [/tmp/wireshark/epan/.libs/libwireshark.so.0.0.0] 256,390,635 > ???:g_slice_free1 (2435843x) [/usr/lib64/libglib-2.0.so.0.3600.4] - pinfo->proto_data, fd->pfd (~0.7%, or 1.2% when no filtering) 194,007,044 * ???:p_add_proto_data [/tmp/wireshark/epan/.libs/libwireshark.so.0.0.0] 122,865,401 > ???:g_slist_insert_sorted (893907x) [/usr/lib64/libglib-2.0.so.0.3600.4] [more than 50% in slice allocator] 739,310,064 * ???:epan_dissect_reset [/tmp/wireshark/epan/.libs/libwireshark.so.0.0.0] 68,198,431 > ???:g_slist_free (583479x) [/usr/lib64/libglib-2.0.so.0.3600.4] 24,222,093 * ???:frame_data_destroy [/tmp/wireshark/epan/.libs/libwireshark.so.0.0.0] 21,616,060 > ???:g_slist_free (187951x) [/usr/lib64/libglib-2.0.so.0.3600.4] This, or next week I'll try to do tvb. Cheers, Jakub. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] How to define HAVE_SSE42 with autotools?
Hello, On Tue, Jun 10, 2014 at 05:06:24PM +, Anders Broman wrote: > >From: wireshark-dev-boun...@wireshark.org > >[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Guy Harris > > > >HAVE_SSE42 is used in two places: > > > > 1) wsutil/ws_mempbrk_sse42.c, where it controls whether to build that > > file at all; > > > > 2) wsutil/ws_mempbrk.c, where it controls whether to check whether the > > CPU has SSE 4.2 and, if it does, call the SSE 4.2 version of the code. > > > >So what HAVE_SSE42 really seems to mean is "does the compiler support the > >intrinsics used in wsutil/ws_mempbrk_sse42.c?" > > > >Should we, instead, check for compiler support for those intrinsics? > > Yes I guess... > > >And will the compiler generate code for those intrinsics, using the SSE 4.2 > >instructions, even if you haven't told it, with a command-line option, to > >generate SSE 4.2 code in general? Or does the >compiler not do a good job > >of supporting choosing whether to use SSE 4.2 instructions at run time > >rather than at compile time? > > I have recently added some macros I found that define HAVE_SSE4_2 so at least > the stuff compiles now on all the buildbots(I think). > > I'm not sure if there should be a command line option or not. But ideally we > should compile ws_mempbrk_sse42.c if the compiler supports it and check > cpu_info() at runtime to use it or not. What about using simple standard AC_TRY_COMPILE( )? something like: #v+ AC_MSG_CHECKING([whether the compiler support -msse4.2 and if there is nmmintrin.h header]) save_CFLAGS="$CFLAGS" CFLAGS="$CFLAGS -msse4.2" AC_TRY_COMPILE( [#include ], [return 0;], [ ac_cv_wireshark_have_sse42=yes AC_DEFINE(HAVE_SSE42,,[Support SSSE4.2 (Streaming SIMD Extensions 4.2) instructions]) AC_MSG_RESULT([yes]) ], [ ac_cv_wireshark_have_sse42=no AC_MSG_RESULT([no]) ]) dnl build libwsutil_sse42 only if there is SSE4.2 AM_CONDITIONAL(SSE42_SUPPORTED, test "x$ac_cv_wireshark_have_sse42" = "xno") CFLAGS="$save_CFLAGS" #v- + uncommented if SSE42_SUPPORTED in wsutil/Makefile.am Anders it's ok for you? I like idea to force (don't do runtime detection) SSE4.2 if -msse4.2 is supported & host CPU support can do sse4.2, but I think it's not worth troubles :) With Regards, Jakub. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [PATCH] reduce scope of and close a file descriptor in wsutil/sha1.c
On Mon, Jun 09, 2014 at 07:32:49PM +0200, Toralf Förster wrote:
> spotted by cppcheck
>
> Signed-off-by: Toralf Förster
> ---
> wsutil/sha1.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/wsutil/sha1.c b/wsutil/sha1.c
> index fcafd2b..081881a 100644
> --- a/wsutil/sha1.c
> +++ b/wsutil/sha1.c
> @@ -426,6 +427,8 @@ int main( int argc, char *argv[] )
> {
> sha1_update( &ctx, buf, i );
> }
> +
> +ws_close(f);
^^^ fclose(f) ?
ws_close() seems to be taking file descriptor.
Cheers,
Jakub.
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Profiling results with optimized function ws_mempbrk_sse42() ws
Hi,
On Wed, Jun 04, 2014 at 11:24:59AM +, Anders Broman wrote:
> I did a test with
> static inline const guint8*
> guint8_pbrk(const guint8* haystack, size_t haystacklen _U_, const guint8
> *needles, guchar *found_needle)
> {
> const guint8 *result = (const guint8 *)strpbrk(haystack,
> needles);
>
> if (result && found_needle)
> *found_needle = *result;
>
> return result;
> }
>
> Which seems to give as good results on Ubuntu 13.10, it ends up using
> __strpbrk_sse42 (libc-2.17.so: strcspn-c.c, ...)
> ==29458==
> ==29458== Events: Ir
> ==29458== Collected : 21130728727
> ==29458==
> ==29458== I refs: 21,130,728,727
> Load time in WS 0:19.300
Yep, ws_mempbrk_sse42() is based on __strpbrk_sse42(), and it should give
similar results.
Still we must have binary (string, length) search, and strpbrk() works
correctly only for NUL terminated string.
Our tvb's are not NUL terminated, and strpbrk() won't skip over NULs, so we
need some modification.
Cheers,
Jakub.
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Compiling with GCC enabling sse4.2?
Hi, On Tue, Jun 03, 2014 at 08:37:49AM +, Anders Broman wrote: > How do I go about compiling Wireshark with sse4.2 enabled? If I understand > correctly I should add GCC flag -march=native somewhere? Anders, just to let you know your libc is already using sse4.2 and it shows up in your profiles: 1,069,870 > /build/buildd/eglibc-2.17/string/../sysdeps/x86_64/multiarch/strcmp-sse42.S:__strcmp_ **sse42** (37467x) [/lib/x86_64-linux-gnu/libc-2.17.so] 1,832,321 > /build/buildd/eglibc-2.17/string/../sysdeps/x86_64/multiarch/strcmp-sse42.S:__strncmp_ **sse42** (66829x) [/lib/x86_64-linux-gnu/libc-2.17.so] I'm not sure if your $CC will generate more sse4.2 in wireshark, still for sure if you pass -march=native -O3 it should be faster, (it should be even more faster when you compile with -flto ;)). Anyway the proper way for autotools is to do: export CFLAGS="-O2 -march=native -pipe" ./configure Cheers, Jakub. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] BItfields Larger than 32 Bits
Hi, On Tue, May 13, 2014 at 02:19:51PM -0400, Kevin Cox wrote: > I was attempting to dissect a 64 bit bitfield and was wondering what the > best/preferred method was. I saw a question on ask.wireshark.org[0] > which had a single answer the said to use a text field. > > [0] > http://ask.wireshark.org/questions/20599/dissecting-bitfields-larger-than-32-bits > > I was wondering if there is a better way to do this. Could you check proto_tree_add_split_bits_item_ret_val()? It looks someone had already this problem. Cheers, Jakub. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Rename TVB captured length vs reported length
Hi, On Mon, Feb 17, 2014 at 05:07:04PM -0500, Evan Huus wrote: > After yet another patch submission where this was unclear, I would > like to propose the following change: > > tvb_length, tvb_length_remaining, etc. are changed to all operate on > the reported length on the wire > > tvb_reported_* are dropped in favor of tvb_captured_* which operate on > the available captured length (what is currently given by just > tvb_length). > > The problem is that 95% of the time the intended behaviour is best > achieved by the reported length, What's the use case of remaining 5%? Heuristic dissectors? ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] ** CID 280353: Operands don't affect result (CONSTANT_EXPRESSION_RESULT) /text2pcap.c: 522 in in_checksum()
On Sun, Feb 09, 2014 at 10:48:44AM +0100, Toralf Förster wrote: > Furthermore I wonder why an undefined value in epan/crypt/airpdcap_interop.h > (around line 98) : > > #ifndef ntohs > #undef ntohs <-- > #define ntohs(value)g_ntohs(value) > #endif > > has to be undef again ? Or does "#ifndef" also check for a defined, but empty > variable ? I don't think so, it's likely a typo, introduced in r20274 (2.01.2007), so I think '#undef' can be safety removed. Or better - if this code is not synchronized with 3rd party (CACE/Riverbed) code, I think we can just use always g_ntohs() there. Kuba. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] tvb_get_string_enc() doesn't always return valid UTF-8
On Tue, Jan 21, 2014 at 08:01:15AM -0500, Evan Huus wrote: > On Tue, Jan 21, 2014 at 2:40 AM, Guy Harris wrote: > > > > On Jan 20, 2014, at 5:59 PM, Evan Huus wrote: > > > >> In which case is dumb search-and-replace of tvb_get_string with > >> tvb_get_string_enc and ENC_ASCII an easy way to make (part of) the API > >> transition? > > > > Did somebody say that had been done or suggest that it be done? > > I thought it was kind of implied when you wrote "We should also > probably audit all calls to tvb_get_string() and tvb_get_stringz() in > dissectors and change them to tvb_get_string_enc() with the > appropriate encoding." > > If tvb_get_string() behaves identically to tvb_get_string_enc(... > ENC_ASCII) then there doesn't seem much point in having both. We can also think about dropping STR_ASCII, STR_UNICODE stuff. To be honest I'm not happy about it, I'd rather still display non-printable ascii in escaped-hex-form. Cheers, Kuba. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] tvb_get_string_enc() doesn't always return valid UTF-8
Hi, On Mon, Jan 20, 2014 at 06:22:37PM +0100, Martin Kaiser wrote: > if I have a tvbuff that starts with 0x86 and I call > > a = tvb_get_string_enc(tvb, 0, ENC_ASCII) > proto_tree_add_string(..., a); > > I can trigger the DISSECTOR_ASSERT since a is not a valid unicode string. > > Comments in the code suggest that tvb_get_string() should replace > chars>=0x80 with the unicode replacement char, which is two bytes long. > This would look like > [...] > > The resulting string would still contain len+1 chars but not necessarily > len+1 bytes. Would that be a problem, i.e. is it ok to do sth like > > b = tvb_get_string(NULL, tvb, offset, len_b); > copy_of_b = g_malloc(len_b+1); > memcpy(copy_of_b, b, len_b+1); If you just want to duplicate string you should definitely use g_strdup() ;-) > If that should work, we'd need a separate function for get string & > replace 8bit chars. I think we don't need, tvb_get_string_enc(, ENC_ASCII) should return valid UTF-8 string, and all callers assuming it's just 1:1 copy are buggy. Maybe we should add: ENC_STRING_DONT_CONVERT, if people want just to have NUL terminated string? btw. I really wonder if current way of using a replacement character is good one. Maybe we should escape it to some: \x86. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Byte ordering for dissectors
Hi, On Fri, Jan 10, 2014 at 01:33:49PM +0100, Michal Labedzki wrote: > Probably PCAP/PCAPNG have ordering info by magic bytes, but I do not > know how to do that while live capturing (current code work for this > case) Still magic numbers are always saved in current host endianess ;| So if you (re)save capture file in wireshark (e.g. after adding comment), it'll be no longer properly dissected. > Possible solutions: > 1. Wireshark already support byte-ordering information for dissectors > (anyone seen, anyone knows?) In packet-nflog.c I'm trying to guess endianess (nflog_tvb_byte_order()) You probably can do the same, looking at dissect_linux_usb_pseudo_header() I'm guessing that: - usb_urb_ts_sec - I think you can assume that all time are smaller than 0x, which for valid captures will be correct to about: 'Sun Feb 7 07:28:15 CET 2106', - usb_urb_ts_usec must be < 100 (false detection only for 256 values), - usb_status must be 0 or have high bit set (false detection only for -EPERM), - usb_urb_len, usb_urb_data_len - must be some sane values (?). Hope that helps, Kuba. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] fighting for dissector independence
On Mon, Dec 30, 2013 at 01:51:28PM -0500, mman...@netscape.net wrote: > print.c - hf_ fields from from frame and data dissectors in order to output > data values. Move it to ui/ ? ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] PCap-NG support in Wireshark and Tshark
On Sun, Dec 29, 2013 at 03:41:05AM -0800, Guy Harris wrote: > > On Dec 18, 2013, at 4:46 AM, Matthias Lang > wrote: > > > 1. The manpage (tshark.pod) for 'tshark' says reading from stdin isn't > > allowed. But it actually works fine. Manpage says: > > > >| =item -r EinfileE > >| > >| Read packet data from I, can be any supported capture file > > format > >| (including gzipped files). It's B possible to use named pipes > >| or stdin here! > > > > Here's what happens, i.e. it works just fine: > > That text might have been historically correct; some changes have been made > to libwiretap to attempt to make it work, at least with some capture file > formats: > [...] > Fortunately, both pcap and pcap-ng formats have magic numbers near the > beginning, and their open routines are called before other ones (as they're > the native formats for Wireshark), so reading pcap or pcap-ng files from a > pipe will probably work (although the pcap file reader does some additional > reading to try to handle some non-standard pcap formats, and if *that* reads > more than will fit in a buffer, the pcap-ng reader won't get to read the file > as the seek-to-the-beginning will fail on a pipe). > > So it's more like "it might, or might not, be possible to read from a pipe > here, depending on the file type and the contents of the file". It doesn't always work with pcap-ng, for example check bug #9533 [1]. [1] https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9533 Kuba. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Changing isprint to g_ascii_print
Hello, I removed isprint.h file, and replaced all isprint() using this hack to g_ascii_isprint(). I've also simplify: isascii && isprint() to g_ascii_isprint() This changes seems correct, but please review. Still we have lot of isprint() calls (some in Qt) which I think should be using g_ascii_*() [1]. Please check. Thanks, Kuba. [1] https://developer.gnome.org/glib/2.28/glib-String-Utility-Functions.html#g-ascii-isalnum ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Converting to new proto tree too complex/errorprone
Hello, On Sat, Dec 21, 2013 at 11:27:27AM +0100, Joerg Mayer wrote: > converting a dissector to the new proto tree api is still unnecessarily > complex (and I managed to break all buildbots in the course). > I've attached a diff between the result of the conversion script output > and the currently committed source. Can you please take a look whether > at least some of this can be improved (if the script had been in perl > I'd probably would have tried to fix some of these things myself). It might be possible to replace proto_peekremote / add NEW_PROTO_TREE_API define before config.h include. Still if we're no longer forced to have header_field_info in register routine, I was thinking we could put hfi just before use. You can check sample in packet-netlink-sock_diag.c, which I base on packet-mpeg-descriptor.c Also Peter suggested some modification to create HFI_REG_VAR macro[1]. btw. recently I have been doing some research if it's possible to do this kind of optimization using clang/ gcc plugins. Right now I have no code. [1] https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9498#c16 ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Replacing g_iconv and different codesets
On Fri, Dec 20, 2013 at 11:59:20AM -0800, Michael Lum wrote: > Okay, thanks for the responses. > > I started to make some changes but its probably more than I have time for. > > But in case I pick it up I had a question about the ENC_ values from proto.h. > > This is what I have from SVN: > > #define ENC_CHARENCODING_MASK 0x7FFE /* mask out byte-order bits */ > #define ENC_ASCII 0x > #define ENC_UTF_8 0x0002 > #define ENC_UTF_16 0x0004 > #define ENC_UCS_2 0x0006 > #define ENC_EBCDIC 0x0008 > #define ENC_WINDOWS_12500x000A > #define ENC_ISO_8859_1 0x000C > #define ENC_ISO_8859_2 0x000E #define ENC_ISO_8859_3 0x0010 #define ENC_ISO_8859_4 0x0012 > #define ENC_ISO_8859_5 0x0014 #define ENC_ISO_8859_6 0x0016 #define ENC_ISO_8859_7 0x0018 #define ENC_ISO_8859_8 0x001A > #define ENC_ISO_8859_9 0x001C #define ENC_ISO_8859_10 0x001E #define ENC_ISO_8859_11 0x0020 /* #define ENC_ISO_8859_12 0x0022 */ #define ENC_ISO_8859_13 0x0024 #define ENC_ISO_8859_14 0x0026 #define ENC_ISO_8859_15 0x0028 Hope that helps. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Replacing g_iconv and different codesets
On Fri, Dec 20, 2013 at 10:46:29AM -0800, Michael Lum wrote: > Is there a goal to remove g_iconv calls from Wireshark. Nope, it's not a goal (at least not for me). Goals are two: 1/ To support more encodings in epan, which will make it easier for people to use 2/ Thanks to 1/ more calls can be changed to proto_tree_add_item() which will not convert text, if it's not required (which should save some CPU cycles). > The other is EUC-KR (Korean). I tried to find a code page that looks like > the ISO ones but I'm not how these > conversions are supposed to work. glibc iconv is licenced under LGPL-2 so you could use it source. In euc-kr [1] you can see that it's using ksc5601_to_ucs4() which can be find in ksc5601.h [2]. ksc5601_to_ucs4() is using convertation tables: __ksc5601_hangul_to_ucs, __ksc5601_hanja_to_ucs, __ksc5601_sym_to_ucs from ksc5601.c [3]. These tables are quite big (about 1K lines) and __ksc5601_sym_to_ucs is using C99 array index initialization (which you would need to expand (covert to switch?) before commiting). So I'd rather suggest still using g_iconv() for EUC-KR, but feel free to introduce new ENC_EUC_KR and move it to core. Cheers, Kuba. [1] https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=iconvdata/euc-kr.c;hb=HEAD [2] https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=iconvdata/ksc5601.h;hb=HEAD [3] https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=iconvdata/ksc5601.c;hb=HEAD ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] proto_field_is_referenced
On Sat, Nov 23, 2013 at 02:23:54PM -0500, mman...@netscape.net wrote: > Is proto_field_is_references still a valid function? > > In looking at the intent, it either looks completely useless or should be > used on almost all dissectors. My old mail about proto_field_is_references() http://www.wireshark.org/lists/wireshark-dev/201205/msg00028.html I think 3/ is already fixed. 1 & 2 are still an issue. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] large signed 40-56bit integers
On Sat, Dec 14, 2013 at 07:44:02PM -0500, mman...@netscape.net wrote:
>
> There is a bug in Wireshark when a dissector has an hf_ variable of type
> FT_INT64 and the requested length of the field is < 8 bytes. There is no
> accounting for the sign bit (which has led dissectors to come up with their
> own solutions). The attached patch attempts to address it. The questions I
> have is
>
> 1. Are these the right places to modify? I thought about pint.h, but I
> didn't know how to get the "sign check" in there.
> 2. Is this cross-platform friendly? (I realize it may not be the most
> optimized solution)
> 3. Did I go far enough in addressing the "common" uses? Is FT_INT40, etc
> necessary?
>
> Any other thoughts?
+gint64
+tvb_get_letohi56(tvbuff_t *tvb, const gint offset)
+{
+ const guint8 *ptr;
+ guint64 ret;
+
+ ptr = fast_ensure_contiguous(tvb, offset, 7);
+ ret = pletoh56(ptr);
just: ret = tvb_get_letoh56(tvb, offset); ?
+ if (ret & 0x80) /* account for sign bit */
+ ret |= 0xFF00;
why 0x80? I think it should be:
if (ret & 0x0080LL) /* (1LL << 55) */
ret |= 0xff00LL /* -(1LL << 56) */
Thanks for working on it.
Cheers,
Kuba.
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] FT_BYTES hf with len==0
Hi, On Mon, Dec 16, 2013 at 05:48:12PM +0100, Martin Kaiser wrote: > is it allowed to add an FT_BYTES hf entry with len==0 to the protocol > tree? > > E.g. > > proto_tree_add_bytes_format_value(tree, hf_myproto_myval, >tvb, offset, 0, NULL, format, ...) > > The idea would be to allow filtering for this element although it has no > value (it's just there). > > When I do this, I run into an assert in proto_custom_set(), > >case FT_BYTES: > bytes = (guint8 *)fvalue_get(&finfo->value); >... bytes_to_string(bytes, ...) -> DISSECTOR_ASSERT > > > Who's at fault here: proto_custom_set() or the caller? proto_item_fill_label() allows empty bytes: 5389 case FT_BYTES: 5390 case FT_UINT_BYTES: 5391 bytes = (guint8 *)fvalue_get(&fi->value); 5392 label_fill(label_str, 0, hfinfo, 5393 (bytes) ? bytes_to_str(bytes, fvalue_length(&fi->value)) : ""); 5394 break; It'd be good to make them consistent, allow empty bytes (+1 from me) or assert in both place. The check in proto_item_fill_label() is almost from begining (r1979). Kuba. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Val_to_str as a macro
Hi, On Wed, Dec 11, 2013 at 05:22:31PM -0500, Evan Huus wrote: > I've been exploring a few options for the val_to_str function and > wmem. One of the tangential things I've been trying to achieve is to > make it into a macro so that the compiler will catch format-string > mismatches (which have been a source of bugs in the past). This is > easy to do inefficiently: > > #define val_to_str(VAL, VS, POOL, FMT) (try_val_to_str(VAL, VS) ? > try_val_to_str(VAL, VS) : wmem_strdup_printf(POOL, FMT, VAL)) > > but I've been unable to find a nice way to avoid the second call to > try_val_to_str(). I can wrap it in a block and use a temporary > variable, but then it can't return a value and no longer behaves like > the original function. We could use GCC extension: http://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html (MSVC can't check format types anyway). > Can anybody else think of a nice way to do this, or is it just one of > those things that's impossible in C? Or more portable: I'd try moving val_to_str() as inline function to value_string.h and later just to test with something like: val_to_str(0, NULL, "%s"); Kuba. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Move plugins/ to epan/dissectors/plugins/
On Wed, Dec 11, 2013 at 09:17:00PM +0100, Joerg Mayer wrote: > On Wed, Dec 11, 2013 at 08:38:30AM +0100, Joerg Mayer wrote: > > I'd like to move the plugins/ directory into epan/dissectors/. They provide > > just more dissectors and depend on epan anyway. > > Are there good reasons not to do that move? > > Replying to self after reading the current state of feedback. OK, I should > have explained my intention more thoroughly :-) > > - I intend to move the directories inside plugins/ into epan/dissectors/ Intention is to clean-up top level directory? If yes, I'd first start with smaller directories like: fix/, idl/, radius/, tpncp/, wimaxasncp/ Just my 3 cents. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] rev 53827: /trunk/epan/ /trunk/epan/dissectors/: packet-ip.c packet-ipv6.c packet-json.c /trunk/epan/: proto.c
On Mon, Dec 09, 2013 at 04:20:58PM +0100, Joerg Mayer wrote: > Isn't UNICODE a bit to broad a name here? Wouldn't STR_UTF8 be a better > name as there are different unicode encodings around? Well I'd rather avoid using any unicode encoding name here, because some people can think: "Hey, I'm using UTF-8, so I just put STR_UTF8 here", or "Hey, my protocol is using UCS-2, so why I need to put STR_UTF8 here?" STR_UNICODE is broad, which is good. Kuba. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] r53871, test.sh decryption failure
On Sun, Dec 08, 2013 at 11:08:39PM +0100, Martin Kaiser wrote: > sorry for causing problems with the DVB-CI decryption test. Don't worry. It's DTLS failing not DVB-CI ;-) Sorry. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Build instability
On Sun, Dec 08, 2013 at 09:23:23PM +0200, Kaul wrote: > Thanks for the automated build links - I guess I'll watch them more closely > and only sync when my platform passes. > > Interesting - I'm pulling from trunk and still fail on that. Perhaps it > wasn't fixed entirely, or I have to do some cleanup? I agree, it isn't fixed, from_hex() is defined inside: #if defined(HAVE_LIBGNUTLS) && defined(HAVE_LIBGCRYPT) but it's used outside this #ifdef. Kuba. > > > On Sun, Dec 8, 2013 at 6:51 PM, Hauke Mehrtens wrote: > > > On 12/08/2013 04:30 PM, Kaul wrote: > > > Hi all, > > > > > > I've been trying to enhance a specific dissector for two weeks now. > > > Since I'm afraid of diverging the code (although I'm working on a > > > specific dissector), I update my code base often (~ once a day). > > > Regretfully, 5 times (in 2 weeks!) this has resulted in compilation > > failure. > > > I'm pretty sure (subjectively) this hasn't happened in the past. Any > > > measures we can put (continuous build system?) in place to prevent this? > > > > > > Today's failure (2nd failure only today btw): > > > make[5]: Entering directory `/home/yanivk/wireshark/epan/dissectors' > > > CC libdissectors_la-packet-ssl-utils.lo > > > packet-ssl-utils.c: In function 'ssl_keylog_parse_session_id': > > > packet-ssl-utils.c:4201:9: error: implicit declaration of function > > > 'from_hex_char' [-Werror=implicit-function-declaration] > > > if (from_hex_char(line[2*i]) != > > > (ssl_session->session_id.data[i] >> 4) || > > > ^ > > > packet-ssl-utils.c:4218:5: error: implicit declaration of function > > > 'from_hex' [-Werror=implicit-function-declaration] > > > if (!from_hex(&ssl_session->master_secret, line, len)) > > > ^ > > > cc1: all warnings being treated as errors > > > make[5]: *** [libdissectors_la-packet-ssl-utils.lo] Error 1 > > > > > > Thanks, > > > Y. > > > > Hi, > > > > There are automated build, they are described here: > > http://www.wireshark.org/docs/wsdg_html_chunked/ChIntroAutomated.html > > > > The last build results are here: > > http://buildbot.wireshark.org/trunk/one_line_per_build > > > > The problem you current have was already fixed in current trunk some > > hours ago. > > > > Hauke > > > ___ > Sent via:Wireshark-dev mailing list > Archives:http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] rev 53826: /trunk/epan/ /trunk/epan/: charsets.c charsets.h proto.h tvbuff.c
On Sat, Dec 07, 2013 at 04:53:51PM -0800, Guy Harris wrote: > > On Dec 7, 2013, at 7:02 AM, darkja...@wireshark.org wrote: > > > http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=53826 > > > > User: darkjames > > Date: 2013/12/07 03:02 PM > > > > Log: > > Add string encoding for ISO/IEC 8859-2 (ENC_ISO_8859_2) > > Should code points in the range 0x80-0x9F map to 0x80-0x9F? $ for ((i = 128; i <= 255; i++)); do echo -en "\x`printf %x $i`"; done | iconv -f iso-8859-2 -t ucs-2 | hexdump ## XXX: can it be done easier? 000 0080 0081 0082 0083 0084 0085 0086 0087 010 0088 0089 008a 008b 008c 008d 008e 008f 020 0090 0091 0092 0093 0094 0095 0096 0097 030 0098 0099 009a 009b 009c 009d 009e 009f It's OK for me. Thanks. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Build failures with VS2013
On Sat, Dec 07, 2013 at 04:50:10PM +, Graham Bloice wrote: > Started testing builds with VS 2013 Pro (nmake build), complaints about > redefinitions: > > C:\Program Files (x86)\Windows Kits\8.1\include\um\ws2tcpip.h(531) : error > C2373: 'ws_inet_pton' : redefinition; different type modifiers > E:\Wireshark\trunk\wsutil/inet_v6defs.h(44) : see declaration of > 'ws_inet_pton' > C:\Program Files (x86)\Windows Kits\8.1\include\um\ws2tcpip.h(548) : error > C2373: 'ws_inet_ntop' : redefinition; different type modifiers > E:\Wireshark\trunk\wsutil/inet_v6defs.h(46) : see declaration of > 'ws_inet_ntop' > > Looking at the definitions of these I can't see what's up. I think it's about const in our prototypes / not-const in windows one. > The definitions from ws2tcpip.h: > > #if (NTDDI_VERSION >= NTDDI_VISTA) > WINSOCK_API_LINKAGE > INT > WSAAPI > inet_pton( > _In_INT Family, > _In_PCSTR pszAddrString, > _Out_writes_bytes_(sizeof(IN6_ADDR)) PVOID pAddrBuf > ); > > PCSTR > WSAAPI > inet_ntop( > _In_INT Family, > _In_PVOID pAddr, > _Out_writes_(StringBufSize) PSTRpStringBuf, > _In_size_t StringBufSize > ); > #endif ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] RFC: new types for hfi->display (STR_ASCII, STR_UNICODE), drop proto_tree_add_unicode_string()
On Sat, Dec 07, 2013 at 10:58:35AM -0500, Evan Huus wrote: > On Sat, Dec 7, 2013 at 7:20 AM, Jakub Zawadzki > wrote: > > Hi, > > > > I renamed base_display_e to field_display_e, and added new enums to > > field_display_e, > > but I wonder if it's correct approach. > > > > For FT_ABSOLUTE_TIME we're using seperate enum > > (absolute_time_display_e), so maybe FT_STRING* should also have own enum > > string_display_e ? > > We already have ENC_ASCII, ENC_UTF8, etc. Perhaps > proto_tree_add_string should just take an encoding value instead? Primarly STR_UNICODE is used only during filling label (+ one assertion), and when displaying we have no longer information about ENC_* flag. We could copy it to ->flags, but ->display for strings is wasted, why not use it? We can later add STR_ASCII_WSP or bitmask like: STR_SHOW_LEN, etc.. We could avoid STR_UNICODE by adding encoding flags like you suggest[1], and by fixing tvb_get_string[z]_enc to enforce encoding rules. Like ENC_ASCII -> replace all chr >= 0x80 ENC_UTF8 -> replace invalid UTF-8 sequence and so on.. [1] or by forcing users to call proto_tree_add_string() only with string earlier obtained from tvb_get_string[z]_enc(). Which I think is better solution. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] RFC: new types for hfi->display (STR_ASCII, STR_UNICODE), drop proto_tree_add_unicode_string()
Hi, I renamed base_display_e to field_display_e, and added new enums to field_display_e, but I wonder if it's correct approach. For FT_ABSOLUTE_TIME we're using seperate enum (absolute_time_display_e), so maybe FT_STRING* should also have own enum string_display_e ? Anyway, dissecotrs using proto_tree_add_unicode_string(): packet-gsm_sms.c packet-etsi_card_app_toolkit.c packet-rrc.c packet-ptpip.c packet-lte-rrc.c packet-gmr1_rr.c packet-ansi_637.c Should probably change it back to proto_tree_add_item/ proto_tree_add_string and start using STR_UNICODE display. If you need some extra flag like: STR_UNICODE_DONT_ESCAPE than go on. I'll change packet-ip, packet-ipv6, packet-json. Kuba. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] ASN dissector (re)generation: TypeError: unorderable types: slice() >= int()
On Wed, Dec 04, 2013 at 02:50:37PM +, Kukosa, Tomas wrote: > I have updated Ply in our SVN (rev 53782) to the current version. > Please check if it helps and works with Python 3. I run make in asn/ and I hit one error in isdn-sup /usr/bin/python ../../tools/asn2wrs.py \ -b -k \ -p isdn-sup \ -c ./isdn-sup.cnf \ -s ./packet-isdn-sup-template \ -D . \ -O ../../epan/dissectors \ Addressing-Data-Elements.asn Basic-Service-Elements.asn Embedded-Q931-Types.asn General-Errors.asn Advice-of-Charge-Operations.asn Closed-User-Group-Service-Operations.asn Conference-Add-On-Operations.asn Diversion-Operations.asn MCID-Operations.asn User-To-User-Signalling-Operations.asn Freephone-Operations.asn ASN.1 to Wireshark dissector compiler Traceback (most recent call last): File "../../tools/asn2wrs.py", line 8028, in eth_main() File "../../tools/asn2wrs.py", line 7967, in eth_main ectx.eth_do_output() File "../../tools/asn2wrs.py", line 2130, in eth_do_output self.eth_output_tables() File "../../tools/asn2wrs.py", line 1931, in eth_output_tables self.eth_output_table(fx, rep) File "../../tools/asn2wrs.py", line 1984, in eth_output_table objs_ord.sort(cmp=partial(cmp_fn, cmp_flds=sort_flds, objs=objs)) TypeError: 'cmp' is an invalid keyword argument for this function Everything else regenerate fine (thanks!), got small diff (not related to your change) and commited it in r53791. Kuba. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] ASN dissector (re)generation: TypeError: unorderable types: slice() >= int()
Hi Tomas, On Tue, Dec 03, 2013 at 10:49:35PM +, Kukosa, Tomas wrote: > I have found that it is the known Ply issue > http://code.google.com/p/ply/issues/detail?id=30 > > I will look whether it is better to fix yacc.py or to change our asn2wrs.py For me we could also force using python2 in asn/ ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] rev 53765: /trunk/epan/ /trunk/epan/dfilter/: dfilter-int.h dfilter.h /trunk/epan/: column-info.h
Hi, On Tue, Dec 03, 2013 at 11:56:23PM +0100, Joerg Mayer wrote: > On Tue, Dec 03, 2013 at 08:59:26PM +, darkja...@wireshark.org wrote: > > http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=53765 > > > > User: darkjames > > Date: 2013/12/03 08:59 PM > > > > Log: > > struct _dfilter_t: rename to epan_dfilter. > > > > typedef (dfilter_t) not renamed. > > This breaks compilation in two places for me: > [ 0%] Building CXX object ui/qt/CMakeFiles/qtui.dir/display_filter_edit.cpp.o > /home/jmayer/work/wireshark/svn/trunk/ui/qt/display_filter_edit.cpp: In > member function ???void DisplayFilterEdit::checkFilter(const QString&)???: > /home/jmayer/work/wireshark/svn/trunk/ui/qt/display_filter_edit.cpp:260:5: > error: ???dfilter_t??? was not declared in this scope > dfilter_t *dfp; > ^ > [etc] More likely next commit - r53766, Guy should have fix it in r53772 (missing includes). ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] ASN dissector (re)generation: TypeError: unorderable types: slice() >= int()
Hi,
I hit this problem when trying to regenerating few ASN dissectors:
/usr/bin/python ../../tools/asn2wrs.py \
-E -b -L \
-p dap \
-c ./dap.cnf \
-D . \
dap.asn DirectoryAccessProtocol.asn
ASN.1 to Wireshark dissector compiler
Traceback (most recent call last):
File "../../tools/asn2wrs.py", line 8028, in
eth_main()
File "../../tools/asn2wrs.py", line 7959, in eth_main
ast.extend(yacc.parse(f.read(), lexer=lexer, debug=pd))
File "/tmp/wireshark/tools/yacc.py", line 265, in parse
return self.parseopt_notrack(input,lexer,debug,tracking,tokenfunc)
File "/tmp/wireshark/tools/yacc.py", line 971, in parseopt_notrack
p.callable(pslice)
File "../../tools/asn2wrs.py", line 7201, in p_cls_syntax_3
t[0] = { get_class_fieled(' '.join(t[1:-1])) : t[-1:][0] }
File "/tmp/wireshark/tools/yacc.py", line 198, in __getitem__
if n >= 0: return self.slice[n].value
TypeError: unorderable types: slice() >= int()
After changing PYTHON= to python2 it works OK, so problem is with python 3.X
(3.2.5?)
Kuba.
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Merging wiretap pint macro to wsutil/pint.h
On Thu, Nov 28, 2013 at 01:40:31PM -0800, Guy Harris wrote: > > On Nov 28, 2013, at 1:39 PM, Jakub Zawadzki wrote: > > > On Tue, Nov 19, 2013 at 07:15:54PM +0100, Jakub Zawadzki wrote: > >> htons(), htonl(), htonll() is kinda easier to write and looks prettier for > >> me than hton16, hton32, hton64(). > > > > It seems that such change would get us to have name conflict with > > (at least on Linux), > > phtoXX() take a pointer and handles unaligned data; renaming them won't cause > a conflict with the Linux #defines. > > htoXX() take an argument and just byte-swaps as necessary; they're currently > just wrappers for GLib macros: > > /* Turn host-byte-order values into little-endian values. */ > #define htoles(s) GUINT16_TO_LE(s) > #define htolel(l) GUINT32_TO_LE(l) > > so one option would simply be to get rid of htoles() and htolel() and just > use the GLib macros directly. If we want to go this way (use glib macros directly), we can also kill BSWAP16, BSWAP32, BSWAP64 macros, and replace with: GUINT16_SWAP_LE_BE, GUINT32_SWAP_LE_BE, GUINT64_SWAP_LE_BE Ok? ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Merging wiretap pint macro to wsutil/pint.h
On Tue, Nov 19, 2013 at 07:15:54PM +0100, Jakub Zawadzki wrote: > htons(), htonl(), htonll() is kinda easier to write and looks prettier for me > than hton16, hton32, hton64(). It seems that such change would get us to have name conflict with (at least on Linux), ../../wsutil/pint.h:154:9: warning: 'htole16' macro redefined /usr/include/endian.h:64:11: note: previous definition is here ../../wsutil/pint.h:155:9: warning: 'htole32' macro redefined /usr/include/endian.h:69:11: note: previous definition is here I can #ifndef it (still man 3 endian.h don't indicate these to be macros), or prepend ws_. I'm not happy with both. Kuba. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] proto_field_is_referenced
On Sat, Nov 23, 2013 at 02:23:54PM -0500, mman...@netscape.net wrote: > I was leaning more towards useless because I can't think of a scenario where > tree (is already) != NULL, yet a dissector would be called without having its > proto field referenced. I don't understand this. For example 'frame.*', 'ip.*' is not referenced, still frame and ip dissector must be called because 'tcp.*' might be refereced. Could you elaborate? Kuba. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] rev 53473: /trunk/ui/ /trunk/ui/gtk/: main_menubar.c /trunk/ui/qt/: main_window_slots.cpp
On Thu, Nov 21, 2013 at 08:46:06AM -0500, Evan Huus wrote: > I don't see any specific reason to keep the proto_ variables private, > so I have no objection to making them available. All of the protocols > involved in this case already have separate header files anyways. I'd rather use proto_get_id_by_filter_name() in some init function, and later compare. Making variables extern is somehow tempting, like we could extern dissector handles and stop using find_dissector() ;] But I think it's wrong way. Kuba. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] offset incrementation in packet-ssl.c (was: r53416: Add status_request_v2 TLS extension dissection (RFC6961))
Hello Alexis, Peter, Looking at r53416 [1] diff, I found two things in packet-ssl.c strange 2861 dissect_ssl3_hnd_hello_ext_status_request_v2(tvbuff_t *tvb, proto_tree *tree, 2869 while (list_len-- > 0) 2870 offset += dissect_ssl3_hnd_hello_ext_status_request(tvb, tree, offset, TRUE); // but dissect_ssl3_ocsp_response() return offset not delta. 3929 dissect_ssl3_hnd_cert_status(tvbuff_t *tvb, proto_tree *tree, 3950 while (list_len-- > 0) 3951 offset += dissect_ssl3_ocsp_response(tvb, tree, offset, pinfo); // but dissect_ssl3_ocsp_response() return offset not delta. I think in both cases it should be '=' not '+=' Could you please check it? Thanks, Kuba. [1] http://code.wireshark.org/git/?p=wireshark;a=commitdiff;h=123e3d92039770c0a36c4be97ae34c1ef27c4f8e ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Merging wiretap pint macro to wsutil/pint.h
On Mon, Nov 18, 2013 at 03:34:44PM -0800, Guy Harris wrote: > I think using the number of bits is cleaner, but going that way everywhere, > not just in those macros, *would* be a major change (mechanical, but still a > change). I only want to make wtap-int.h use pint.h macros, htons(), htonl(), htonll() is kinda easier to write and looks prettier for me than hton16, hton32, hton64(). But it's 2 against 1, so I will make suggested change. Thanks for opinion. Cheers, Kuba. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Merging wiretap pint macro to wsutil/pint.h
Hello, Right now we have the similar set of macros inside wtap-int.h & pint.h. I'd like to merge wtap-int.h macros to pint.h The main difference is in naming of 64-bits version. In pint.h it ends with 64 (pntoh64, pletoh64) in wtap it ends with ll (pntohll, pletohll, phtonll, phtolell, htolell) Which one we prefer? To be honest I'm bigger fan of 'll'. If we want to use '64' I think it'd be also good to rename s[hort] and l[ong] version to match convention: pntohs -> pntoh16 pntohl -> pntoh32 ... htoles -> htole16 htolel -> htole32 Cheers, Kuba. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] buildbot failure in Wireshark (development) on Windows-7-x64
On Sat, Nov 16, 2013 at 11:12:22PM +0100, Jakub Zawadzki wrote: > (...) Still it seems to be quite complicated for one bitswap variable... > (revert?). I've added bitswap_buf_inplace() in r53374, r53375 This seems to be nice fix. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] buildbot failure in Wireshark (development) on Windows-7-x64
On Sat, Nov 16, 2013 at 12:25:53PM -0800, Guy Harris wrote: > > On Nov 16, 2013, at 1:54 AM, buildbot-no-re...@wireshark.org wrote: > > > The Buildbot has detected a new failure on builder Windows-7-x64 while > > building Wireshark (development). > > Full details are available at: > > http://buildbot.wireshark.org/trunk/builders/Windows-7-x64/builds/7888 > > > > Buildbot URL: http://buildbot.wireshark.org/trunk/ > > > > Buildslave for this Build: windows-7-x64 > > > > Build Reason: scheduler > > Build Source Stamp: 53366 > > Blamelist: darkjames > > > > BUILD FAILED: failed nmake all > > Would somebody with sufficient Windows build experience care to indicate what > the right way is to handle a variable (not a function) that is: > > exported by library A; > > imported by library B; > > declared in a header file that's included by the source file in library > A that defines the variable and by the source files in library B that use the > variable? > > The problem is that the source file in library A *and* the source files in > library B are *both* compiled with "this is going into a DLL" flag on > Windows, as they *are* all going into DLLs on Windows, so that -D flag cannot > be used to control whether the declaration in the header file is "this is > being exported" (__declspec(dllexport)) and "this is being imported" > (__declspec(dllimport)). Ups, my fault. Looking how it's done in glib (GLIB_VAR definition [1]): # ifdef G_PLATFORM_WIN32 # ifdef GLIB_COMPILATION # define GLIB_VAR __declspec(dllexport) # else /* !GLIB_COMPILATION */ #define GLIB_VAR extern __declspec(dllimport) # endif /* !G_PLATFORM_WIN32 */ In our bulding system the similar thing of GLIB_COMPILATION does WS_BUILD_DLL, but it's always set when building library i.e. epan, wiretap, wsutil. So we can't have one WS_BUILD_DLL because we need to distinguish if we want to export (the same library) or import symbol (different library) or use extern (the same library). in Makefiles: -DWS_BUILD_DLL=EPAN, -DWS_BUILD_DLL=WSUTIL, WS_BUILD_DLL=WIRETAP + instead of one WS_DLL_PUBLIC we need to use some: WS_DLL_PUBLIC(EPAN), WS_BUILD_DLL(WSUTIL)... later in WS_DLL_PUBLIC(x) compare #if x == WS_BUILD_DLL Does it makes sense? Still it seems to be quite complicated for one bitswap variable... (revert?). Kuba. [1] https://git.gnome.org/browse/glib/tree/glib/gtypes.h ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] tshark problem with grouped AVP:s?
Hello Anders, On Thu, Nov 14, 2013 at 04:14:02PM +, Anders Broman wrote: > The following tshark parameters " -Y diameter -z > proto,colinfo,diameter.Experimental-Result-Code,diameter.Experimental-Result-Code" > yields no result where as > -Y diameter -z proto,colinfo,diameter.Result-Code,diameter.Result-Code > > Does the only difference seems to be that the first one is grouped. Looking > at the code I can't see why it shouldn't work - ideas? Any capture file to work on this? ;-) ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] capture_file* in dissector code
On Wed, Nov 13, 2013 at 05:14:19PM -0500, mman...@netscape.net wrote: > A related question - Is packet_info->phdr == &capture_file->phdr? > That would allow me to get the data I need always from packet_info* and not > need the capture_file* Not always, packet_info->phdr points to currently dissecting packet. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] capture_file* in dissector code
Hi, On Wed, Nov 13, 2013 at 08:15:12AM -0500, mman...@netscape.net wrote: > I was looking at making the "Decode As" functionality more generic, but my > current solution involves having dissectors handle a callback function that > passes in a capture_file* as an argument. I'm not sure if it's good enough, but epan_session->data in wireshark, tshark, rawshark points to capture_file * ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] GCC Diagnostic Pragmas
Hi Alexis,
On Sun, Nov 10, 2013 at 11:35:02AM +0100, Alexis La Goutte wrote:
> On Sat, Nov 9, 2013 at 1:39 PM, Jakub Zawadzki
> wrote:
> > In few dissectors we're manually disabling some kind of warnings, like
> > in packet-parlay.c
> >
> > #ifdef _MSC_VER
> > /* disable warning: "unreference local variable" */
> > #pragma warning(disable:4101)
> > #endif
> >
> > It's possible to do the same with GCC (4.6) using diagnostics pragmas[1].
> >
> > Googling around found test:
> >
> > #if __GNUC__ > 4 || (__GNUC__ == 4 && (__GNUC_MINOR__ >= 6 ||
> > __APPLE_CC__))
> > # pragma GCC diagnostic ignored "-Wunused"
> > #endif
> >
> > which seems to be not working with my clang-3.3.
> >
> > qemu does test during configure, trying to compile some test program with
> > -Werror.
> >
> > I think we could do the same, test program can looks like this:
> > #v+
> > #pragma GCC diagnostic push
> > #pragma GCC diagnostic ignored "-Wunused"
> > #pragma GCC diagnostic pop
> >
> > int main(void) {
> > return 0;
> > }
> > #v-
> >
> > OK?
> >
> > [1] http://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html
>
> No problem for me !
> There is some pragma stuff in epan/wsgcrypt.h (i not sure if the hack for
> Clang works).
Nice, we're already using them, thanks for the hint ;-)
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] High speed packet captures - libpcap with TPACKET_V3
Hi, On Sun, Nov 10, 2013 at 11:50:27AM +0100, Anders Broman wrote: > The upcoming libpcap 1.5 have support for TPACKET_V3 which seems to > improve on packet drops at high sped captures. Finally ;-) > However some tests on a 1 Gb link with ~900 Mb/s indicates that tcpdump does > better than dumpcap > possibly because dumpcap uses "inpkts = pcap_dispatch(pcap_opts->pcap_h, > 1, capture_loop_write_packet_cb, (u_char *)pcap_opts);" fetching > packets one by one rather than using -1. Try saving in libpcap (not libpcap-ng) format, try to use threads (or not if you were using them). Does it helps? ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] GCC Diagnostic Pragmas
Hi,
In few dissectors we're manually disabling some kind of warnings, like
in packet-parlay.c
#ifdef _MSC_VER
/* disable warning: "unreference local variable" */
#pragma warning(disable:4101)
#endif
It's possible to do the same with GCC (4.6) using diagnostics pragmas[1].
Googling around found test:
#if __GNUC__ > 4 || (__GNUC__ == 4 && (__GNUC_MINOR__ >= 6 || __APPLE_CC__))
# pragma GCC diagnostic ignored "-Wunused"
#endif
which seems to be not working with my clang-3.3.
qemu does test during configure, trying to compile some test program with
-Werror.
I think we could do the same, test program can looks like this:
#v+
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wunused"
#pragma GCC diagnostic pop
int main(void) {
return 0;
}
#v-
OK?
[1] http://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] rev 53146: /trunk/epan/ /trunk/epan/dissectors/: packet-2dparityfec.c packet-acap.c packet-bitcoin.c packet-data.c packet-daytime.c packet-dbus.c packet-fcdns.c
On Fri, Nov 08, 2013 at 01:27:40AM +0100, Joerg Mayer wrote:
> On Fri, Nov 08, 2013 at 01:03:47AM +0100, Jakub Zawadzki wrote:
> > After r53150 it works with GCC, at least on my Linux ;-)
>
> And after another commit it also works on my system (32-bit Linux with GCC
> 4.8.2),
> so I decided to make it easier to play with this.
> Turns out my mint dissector had an unused element ;-)
Yeah, no longer need for checkhf.pl (which in fact doesn't work with new style
dissectors).
> Hopefully I'll be able to test on windows tomorrow so if a few more tests
> turn out good results the "old" code could be removed.
Windows MSVC doesn't support __attribute__((section)) it has their own
way [1]. It could work with mingw/cygwin.
Even if we implement it for Windows, we can't remove hfi array
completely. There might be systems on which it won't work.
It's good opt-in (binary can be smaller by about 1-2 MB, which will
give us minimally faster startup), but not portable.
We could not emulate arrays using section, but write it explicit (100%
portable!):
enum {
HF_FOO = 0,
HF_BAR
};
struct header_field_info proto_hfi[] = {
{ field_foo },
{ field_bar }
};
proto_tree_add_item( &proto_hfi[HF_FOO] );
proto_tree_add_item( &proto_hfi[HF_BAR] );
but to make maintaince of assigning good index to hfi easier, we'd need C99:
struct header_field_info proto_hfi[] = {
[HF_FOO] = { field_foo },
[HF_BAR] = { field_bar }
};
Which is not supported at least in MSVC, anyway seperate variable for each hf
looks IMHO nicer.
[1]
http://stackoverflow.com/questions/3808053/how-to-get-a-pointer-to-a-binary-section-in-msvc
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] rev 53146: /trunk/epan/ /trunk/epan/dissectors/: packet-2dparityfec.c packet-acap.c packet-bitcoin.c packet-data.c packet-daytime.c packet-dbus.c packet-fcdns.c
On Thu, Nov 07, 2013 at 10:43:26PM +0100, Jakub Zawadzki wrote: > On Thu, Nov 07, 2013 at 09:52:19PM +0100, Joerg Mayer wrote: > > On Thu, Nov 07, 2013 at 08:14:20PM +, darkja...@wireshark.org wrote: > > > http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=53146 > > > > > > User: darkjames > > > Date: 2013/11/07 08:14 PM > > > > > > Log: > > > Add infrastructure for section-initializing protocol hfis (without > > > array). > > > > Nice! > > > > > configure implementation later. > > > > Why make this a configure option instead of just setting it? > > I'd love to say it works on every platform, but unfortunetly it's not true > even on Linux. After r53150 it works with GCC, at least on my Linux ;-) ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] rev 53146: /trunk/epan/ /trunk/epan/dissectors/: packet-2dparityfec.c packet-acap.c packet-bitcoin.c packet-data.c packet-daytime.c packet-dbus.c packet-fcdns.c
On Thu, Nov 07, 2013 at 09:52:19PM +0100, Joerg Mayer wrote: > On Thu, Nov 07, 2013 at 08:14:20PM +, darkja...@wireshark.org wrote: > > http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=53146 > > > > User: darkjames > > Date: 2013/11/07 08:14 PM > > > > Log: > > Add infrastructure for section-initializing protocol hfis (without array). > > Nice! > > > configure implementation later. > > Why make this a configure option instead of just setting it? I'd love to say it works on every platform, but unfortunetly it's not true even on Linux. I was thinking to run program like: http://www.wireshark.org/~darkjames/section-test.c during ./configure Tests done on amd64 gcc-4.6.4 (fail): #v+ $ ./a.out 0x601080 0x601128 -1431655763 ; WTF?! records: -1431655763 2 #v- clang-3.3 (ok): #v+ $ ./a.out 0x602148 0x6021d8 2 records: 2 2 [0] 0x602148 0x602148! [1] 0x602190 0x602190! records: 3 [0] 0x602070: String value json.value.string [0] 0x6020b8: Number value json.value.number [0] 0x602100: Member json.member test ok #v- To be honest this is my first time where I run some serious testing. Earlier I've done tests mostly using clang, and sample program from http://stackoverflow.com/q/3808053 (which works also on GCC). My fault. btw. this looks like alignment issue, cause if I add some dummy field: void *same_name_next; + char dummy[24]; } header_field_info; GCC works. Crazy (why 24?! (8 doesn't work)) not portable stuff. To be dropped, or need some more reading/ mail to GCC devs. Cheers, Jakub ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Coverity warning in tshark.c
Hi Joerg,
On Mon, Oct 21, 2013 at 11:58:17PM +0200, Joerg Mayer wrote:
> Looks like coverity has a valid complaint:
>
> CID 1109702: Dereference after null check (FORWARD_NULL)
>
> /tshark.c: 2859 ( var_compare_op)
>2856 /* If we're going to print packet information, or we're going to
>2857 run a read filter, or we're going to process taps, set up to
>2858 do a dissection and do so. */
> >>> Comparing "edt" to null implies that "edt" might be null.
>2859 if (edt) {
>2860if (gbl_resolv_flags.mac_name || gbl_resolv_flags.network_name
> ||
>2861gbl_resolv_flags.transport_name ||
> gbl_resolv_flags.concurrent_dns)
>2862 /* Grab any resolved addresses */
>2863 host_name_lookup_process();
>
>
> /tshark.c: 2903 ( var_deref_model)
>2900if (print_packet_info) {
>2901 /* We're printing packet information; print the information
> for
>2902 this packet. */
> >>> Passing null variable "edt" to function "print_packet", which
> >>> dereferences it.
>2903 print_packet(cf, edt);
>2904
>2905 /* The ANSI C standard does not appear to *require* that a
> line-buffered
>2906 stream be flushed to the host environment whenever a
> newline is
>2907 written, it just says that, on such a stream, characters
> "are
I don't see a problem.
Previously print_packet() was also passing edt as NULL
- if (do_dissection)
-print_packet(cf, &edt);
- else
-print_packet(cf, NULL);
I simplified it, just to:
+ print_packet(cf, edt);
No idea how to fix it, sorry. Most likely it's false positive.
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] FW: [Wireshark-commits] rev 52730: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-cdp.c
Hi, > User: eapache > Date: 2013/10/21 01:07 PM > > Log: > Don't go into a loop if we find a zero-length line. Fixes > https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9312 > > Anders, this may be related to your recent TVB optimizations, since I don't > think it happened before that? Did you change the behaviour of > tvb_find_line_end or its callees at all? >From tvb_find_line_end() comment: * Set "*next_offset" to the (...) past the end of the buffer if we don't find a line terminator. This was changed, tvb_find_line_end() no longer does it, it sets *next_offset to tvb->length, so there's no exception in next call. I'm also not happy about: 2481 /* tvb_get_guint8() */ 2482 ptr=tvb->real_data + eol_offset + 1; If it really speedup dissection there should be at least DISSECTOR_ASSERT(tvb->real_data != NULL) before. Cheers, Kuba. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] rev 52608: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-vlan.c
On Tue, Oct 15, 2013 at 07:19:34AM +0200, Anders Broman wrote: > Maynard, Chris skrev 2013-10-15 00:47: > > Why not add a fence so it's always visible then? > > My point is that I don't want to write column info in the VLAN dissector > to speed up dissection. If it could > be arranged to only write the "last" entry that will actually be in the > packet list or written out by tshark it would be much more efficient. I was looking on it yesterday, with libffi (nice portable library!) it seems to be possible to call variadic functions (read: g_snprintf) with custom arguments. We need to cache format and arguments and we could do it. Right time no time ;| > In the reference trace I'm pursuing col_add_fstr() costs 7.52 is called > 4,7 million times, where of 2.8 million times is from the VLAN dissector. I'm not sure if it helps, but I micro-optimized print_columns() removing g_snprintf() & g_strlcat() [hope that I keep tshark output the same] in r52625. Looking at callgrind output of some capture file of yours (TCA_SIP_performance.pcap) these calls costs 4,8M. I hope we saved about 1-2G Ir by calling just memcpy(), could you please check in some free time? #v+ 10,589,960,094 * /home/ericsson/ewireshark/trunk/tshark.c:print_packet 3,830,250,718 > ???:g_snprintf (5743212x) [/lib/x86_64-linux-gnu/libglib-2.0.so.0.3600.0] 1,073,058,165 > ???:g_strlcat (1297x) [/lib/x86_64-linux-gnu/libglib-2.0.so.0.3600.0] #v- P.S Thanks for reverting packet-vlan.c ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] r52604: Adding to col info is probably useless as next dissector will overwrite it.
Hi Anders, Please revert it, dissectors after vlan can be disabled. If we want to have some lazy COL_INFO calculation - that's fine for me, but selectively disabling col_add_fstr is NACK for me. Cheers, Jakub. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Idea for process image dissection
Hi, On Sun, Oct 13, 2013 at 10:17:45AM +0200, Roland Knall wrote: > I just wanted to bring something by you guys, if it would be worth > implementing. > > I work on the openSAFETY and EPL dissectors. Both are fieldbus > specific implementations. As such the communicate process images as > payloads. This is the same with nearly all other fieldbus > implementations i know (CanOpen, Profinet, SercosIII, ...). > > As such, to a unknown user this displays simply as a byte payload. Now > it may be useful, to dissect the payload in some cases, as such we may > be able to search for specific fields triggering in the payload. > > For such a dissection, we need to tell a dissector, how to dissect a > specific payload. Have you checked decode as dialog implementation? If you want to make it generic great for me. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] rev 52578: /trunk/epan/ /trunk/epan/: proto.c tvbuff.c tvbuff.h
On Sun, Oct 13, 2013 at 04:43:28PM -0400, Evan Huus wrote: > On Sun, Oct 13, 2013 at 3:54 AM, Jakub Zawadzki > wrote: > > About tvb_offset_exists() comment, compute_offset() is not returning > > exception when offset == tvb->length. > > Ah, OK. Should it? When offset == tvb->length I would think that > should be an exception, since no bytes exist at that location. Don't know, right now it works :} There is some lengthy comment about it before check_offset_length_no_exception(). I know about some dissectors which calls tvb_find_guint8() with offset == tvb->offset [bug #9034#c5]. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] rev 52578: /trunk/epan/ /trunk/epan/: proto.c tvbuff.c tvbuff.h
> On Sun, Oct 13, 2013 at 12:54 AM, wrote: > > http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=52578 > > > > User: eapache > > Date: 2013/10/13 04:54 AM > > > > Log: [...] > > All of this is (theoretically) unnecessary - simply checking the offset > > without > > worrying about the length will still catch the very-long-loops, since it > > is the > > offset that increases in each iteration, not the length. > > > > All that to justify: > > - implement tvb_ensure_offset_exists which throws an exception if the > > offset is > >not within the tvb > > - use it instead of all the complicated other logic in the > > pre-short-circuit > >step of proto_tree_add_item and friends > > > > This gives us back about 3/4 of the performance we lost in the original > > patch. > > We're still ~2% slower than without any check, but this is the best I can > > think > > of right now. > > On Sun, Oct 13, 2013 at 12:58:12AM -0400, Evan Huus wrote: > Jeff (and/or anyone else who cares) I'd appreciate a verification that > my logic here is correct, and that I've not accidentally undone your > good work. I think it's fine, unless in loops there're some weird offset integer overflows (which returns back to offset + 0), like easy case: proto_tree_add_item(..., offset, 0xfffe /* -2 */, ...); offset += (-2); proto_tree_add_item(..., offset, +2, ...); offset += (+2); About tvb_offset_exists() comment, compute_offset() is not returning exception when offset == tvb->length. Kuba. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Idea for faster dissection on second pas
On Sat, Oct 12, 2013 at 05:08:04PM -0400, Evan Huus wrote: > On Sat, Oct 12, 2013 at 12:29 PM, Evan Huus wrote: > > Now I'm wondering how much of this could be alleviated somehow by a more > > efficient tree representation... > > The answer is apparently lots :) We've already had similar benchmark result done, while removing emem slabs: http://www.wireshark.org/lists/wireshark-dev/201303/msg00101.html http://www.wireshark.org/lists/wireshark-dev/201303/msg00105.html > I tweaked some things in r52568, r52569 and r52573 that had a fairly > substantial improvement when dissecting with a tree. "tshark -V" is as > much as 18% faster in my tests, and filtering should improve a little > as well, though that is much harder to measure. Still good we regain this performance (and even better tree free now is O(1)), even if tshark -V might be not normal use case. Thanks. Cheers, Kuba. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Motivation for wmem [was: rev 52264]
On Sun, Sep 29, 2013 at 05:35:59PM -0400, Evan Huus wrote: > On Sun, Sep 29, 2013 at 3:56 PM, Jakub Zawadzki > wrote: > > But back to topic (cause you'll probably see this problem few more times). > > I don't quite get a point why we need to change everything to wmem. > > (To be honest I still don't quite get why we need wmem_ at all, but let's > > skip that). > > Wmem is mostly a replacement for emem, because emem was becoming > impossible to maintain and reason about (recall, for example, bug > #5284). If you could still deal with emem, congratulations, but the > rest of us mortals needed something more comprehensible. Evan, I *really* don't see what wmem_ is fixing. I mostly see that we have few extra assertions to dissallow use it when not dissecting packets. But if we want to remove totally ep_ we'd need to fix this shit anyway. I'm not fan of this, sorry. Right now wmem_ is quite long in our eco system, so this talk is pointless. Please, just let's skip this discussion. I'll make some comments from time to time (/me just being a little conservative), but I think you can life with it? :-) Eventually I might try to lobby replacing wmem_packet_scope() with some pinfo_current()->pool [or pinfo->pool if we have pinfo pointer] - that's all. > > But if we really want to do that (change everything to wmem_), we NEED some > > ep-like temporary pool (which will work both for UI and dissection), > > or some function which will return packet-pool or gui-pool if there's no > > dissection. Otherwise we need to remove some functionality. > > No. This is one of the things I dislike most about emem. Using ep_ > memory outside of packet dissection provides no guarantees at all as > to when that memory is going to be freed, and makes it difficult if > not impossible to reason about scope. The majority of such uses I > expect to be converted to manually-managed memory. If there is some > obvious common UI-scope then we can easily create a new pool for that > memory, but the cases I have reviewed have not had any obvious common > scope, they are simply using ep_ and assuming that it goes away at > some point (and not while they still need it!) Ok, this can be fixed with g_free() after val_to_str_[dup|format]. I'm fine with this. +1 from me. > P.S. I have a pleasant day-dream where libwireshark gets rewritten in > a garbage-collected language like Go, but I somehow suspect that isn't > going to happen... Why Go? if we talk about better languages I'd rather use D. If we talk about glib-language-environment than Vala has reference couting. Still there's popular GC for C: http://www.hpl.hp.com/personal/Hans_Boehm/gc/ and there's alredy interested in using that: http://www.wireshark.org/lists/wireshark-dev/201210/msg00229.html ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] rev 52264: /trunk/ /trunk/epan/: value_string.c value_string.h /trunk/: rawshark.c
On Sun, Sep 29, 2013 at 08:46:23AM -0400, Evan Huus wrote: > On Sun, Sep 29, 2013 at 8:44 AM, wrote: > > http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=52264 > > > > User: eapache > > Date: 2013/09/29 12:44 PM > > > > Log: [...] > > This is one of the first steps towards converting val_to_str and friends to > > wmem. I'm honestly not sure what the best approach is for the API in this > > case: > > the vast majority of usage is within dissectors, so just hard-coding packet > > scope (the way they currently hard-code ep_ scope) doesn't look terrible, > > but > > there are *some* uses in taps and other places that will need to be > > converted to > > something else if we go that route. Adding a wmem_pool parameter just for > > the > > uncommon case seems a bit like overkill, though perhaps it is the right > > thing to > > do. > > Thoughts on this? Most of current calls are done by col_append_fstr() or expert_add_info_format() so it'd be actually great to have own formatting conversion. /me smiles to register_printf_function(), still not portable ;| So... What about removing val_to_str(), val_to_str_const() rename try_val_to_str() to val_to_str() make caller responsible to do what he want when there's no value for value_string entry. value_string API don't allocates memory -> no problem ;] But back to topic (cause you'll probably see this problem few more times). I don't quite get a point why we need to change everything to wmem. (To be honest I still don't quite get why we need wmem_ at all, but let's skip that). But if we really want to do that (change everything to wmem_), we NEED some ep-like temporary pool (which will work both for UI and dissection), or some function which will return packet-pool or gui-pool if there's no dissection. Otherwise we need to remove some functionality. Still I don't see any UI-wmem-pool, do we have one? PS: I know it's obvious, sorry ;| ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Transport name resolution
On Mon, Sep 16, 2013 at 03:17:54PM -0400, Jeff Morriss wrote: > On 09/16/13 14:57, Guy Harris wrote: > > > > On Sep 16, 2013, at 7:20 AM, Anders Broman > > wrote: > > > >> In serv_name_lookup() we call getservbyport() for ports not resolved in > >> the IANA port list the function > >> Seems quite expensive so my question is does it add any value or can I > >> remove it? > > > > At least on UN*Xes, getservbyport() does one or more of: > > > > 1) look in /etc/services, which is probably based on a > > (possibly-out-of-date) version of, err, umm, the IANA port list; > > > > 2) query some network service to do a lookup - and that service is > > probably using its own database, based on a (possibly-out-of-date) version > > of, err, umm, the IANA port list. > > ... possibly with some modifications for local use. But I imagine the > number of people who actually go through the trouble to run a customized > service database to be sufficiently few that it's not worth slowing > everyone else down for. It sounds for me as a good Preference option. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] VALS() with populated "unknown string"
On Mon, Sep 16, 2013 at 06:47:50AM -0400, mman...@netscape.net wrote: > Is there a way to provide the "unknown string" for the val_to_str call made > in hf_ registration (ie some derivation of the VALS() macro)? > There are many proto_tree_add_[u]int_format[_value] calls that are done > strictly to provided an "unknown string" for the val_to_str that is different > than the default of "Unknown". > If there was such a way, many of these calls could be converted to > proto_tree_add_item or proto_tree_add_[u]int. > If there isn't such a thing, how easy/hard would it be to implement? I'd suggest tweaking extended value_string API for it. We'd need first to convert value_string to extended one, but I think it's better than adding new field to header_field_info structure. Regards, Jakub. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Memory consumption in tshark
On Tue, Aug 27, 2013 at 05:09:19PM -0400, Evan Huus wrote: > We already do reassembly and a lot of other stateful work in single-pass > mode. The only thing two-pass mode provides is the ability to "see the > future" (for example, saying: this request has a response 5 packets later). We need two pass also for correct out of order reassembly. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Memory consumption in tshark
On Tue, Aug 27, 2013 at 06:17:13PM -0400, Evan Huus wrote: > As Anders says, this is because we have no way right now to selectively > discard it: much of the data is stored in a way that we can only get rid of > all of it, or none. I'm not sure why we want to do selectvely discard, I'm fan of 'get rid of all of it'. > I'm sure there are some significant improvements we could make if somebody > figures out how, It's quite simple just call epan_free(), epan_new() after each packet (or every N-th packet, or when dissection throw OutOfMemory exception - ups it could be too late ;]) ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Memory consumption in tshark
On Tue, Aug 27, 2013 at 04:37:27PM -0400, Evan Huus wrote: > We already discard a great deal of state in (single-pass) tshark that we > keep around in Wireshark (or two-pass tshark). Really? I'm not so sure about that 'great deal' I think right now we are only freeing protocol frame data list. > I dislike the idea of two-pass by default for exactly this reason: people > expect tshark to be relatively state-less. This is already not the case, > but it's a lot worse in two-pass mode. It might even make sense to add a > --state-less flag to tshark that disables all options which require state. > I don't know how feasible that would be however. If they want state-less they should probably use tcpdump. To be honest I don't like option --state-less (it'd be really hard to find), I'd rather make single pass really state-less (if that's what user expect). And if user want to do pro dissection -2 must be used anyway. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Memory consumption in tshark
Hi, >> From: wireshark-dev-boun...@wireshark.org >> [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Dario Lombardo > >> I've run this command on a 10G pcap file. > >> ./tshark -r traffic.all -Y "dns.qry.name.len > 50" -w longnames.pcap > >> Used memory grows continuously, up to over 3GB of ram. At this point my pc >> goes thrashing and I must kill tshark. >> That's not what I expected. I expected the memory to grow up to a certain >> size, then stop, feeding the output file. >> Any idea about what happens? Any suggestion on how to debug it? On Tue, Aug 27, 2013 at 02:40:07PM +, Anders Broman wrote: > No it will not; as state and stuff accumulates memory grows until *shark runs > out of memory your mileage on Isn't it a bug? Do we need some special option for such case, or reusing single pass tshark is good enough? We should anyway do -2 pass default where we have a file (and not pipe). ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Enabling linux kernel jit compiler from dumpcap?
On Thu, Aug 22, 2013 at 08:45:06PM +0200, Jakub Zawadzki wrote: > On Thu, Aug 22, 2013 at 09:16:04AM -0700, Guy Harris wrote: > > > > On Aug 22, 2013, at 4:46 AM, Anders Broman > > wrote: > > > > > Should we add code to enable the JIT compiler from dumpcap? > > > > Should I add code to enable the JIT compiler to libpcap while I'm at it? > > > > Should the Linux kernel folks enable it by default? > > > > I'm inclined to answer "yes" to all three questions. I think the FreeBSD > > JIT compiler is enabled by default. > > I'm surprised that the Linux one isn't. > > Security issue: > http://mainisusuallyafunction.blogspot.com/2012/11/attacking-hardened-linux-systems-with.html Also it's not perfect like BPF VM, check: https://lkml.org/lkml/2012/3/30/384a Don't know if such instruction can happen in BPF filter generated by libpcap (Guy?). If yes we should not enable in on kernels before it was fixed. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Enabling linux kernel jit compiler from dumpcap?
On Fri, Aug 23, 2013 at 10:23:32AM +, Anders Broman wrote: > > before we change it, should we remember the previous setting and restore it > > when dumpcap exits? > > Preferably yes but I'm not sure it's possible as I think root privileges are > required to write to the file and I think dumpcap > Drops those after starting to capture. I've not looked at kernel sources, but isn't JITing done when attaching filter to socket? And later this sysctl variable takes no effect? so we could do: - enable JIT if not enabled - pcap_setfilter(pcap, program) - disable JIT if enabled - drop privilages It's a little racy, but well... ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Enabling linux kernel jit compiler from dumpcap?
On Thu, Aug 22, 2013 at 09:16:04AM -0700, Guy Harris wrote: > > On Aug 22, 2013, at 4:46 AM, Anders Broman wrote: > > > Should we add code to enable the JIT compiler from dumpcap? > > Should I add code to enable the JIT compiler to libpcap while I'm at it? > > Should the Linux kernel folks enable it by default? > > I'm inclined to answer "yes" to all three questions. I think the FreeBSD JIT > compiler is enabled by default. > I'm surprised that the Linux one isn't. Security issue: http://mainisusuallyafunction.blogspot.com/2012/11/attacking-hardened-linux-systems-with.html ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] rev 51396: /trunk/epan/ /trunk/epan/: proto.c proto.h
On Sat, Aug 17, 2013 at 03:31:47PM +0200, Joerg Mayer wrote: > Can you commit a conversion tool? Sure, r51407 > It has begun - good! The biggest problem during conversation is missing declaration of value_string or tfs. It's not portable (in C++) to do forward declaration of structure (aka http://www.wireshark.org/lists/wireshark-dev/201307/msg00058.html). Right now I sometimes moved value_string to top, sometimes just before hfi declaration (when it was only used for this field). I don't like either way. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] rev 51395: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-rohc.c
By the way from ROHC code: 2296 data = (guint8 *)ep_alloc(len); 2299 next_tvb = tvb_new_child_real_data(tvb, data, len, len); 2300 add_new_data_source(pinfo, next_tvb, "Payload"); It's very bad idea to use ep-allocated tvb as data source. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Remove hf_ variables
On Tue, Aug 13, 2013 at 06:53:42PM +0200, Jakub Zawadzki wrote:
> On Fri, Aug 09, 2013 at 08:31:02PM +0200, Jakub Zawadzki wrote:
> > Removed in v2:
> >
> > http://www.wireshark.org/~darkjames/proto-new-v2/0001-changes.txt
> > http://www.wireshark.org/~darkjames/proto-new-v2/0002-rewrite.txt
> >
> > Changes from v1:
> > - proto_tree_add_item() now takes pointer to header_field_info *,
> >if NEW_PROTO_TREE_API NOT defined small compatilibity macro is used.
> > - convert names just to hfi_ not hfi_hf_
> > - fix proto_get_first_protocol_field(), proto_get_next_protocol_field()
>
> Ping, any feedback?
Ok, commited some work based on v2
HFI_INIT for now is just placeholder (to not modify again lots of lines),
later it'll expand to something like: __attribute__((section("_data_hfi_"
#proto))) (for gcc/clang),
which will allow to #ifndef hfi[] arrays.
This should also obsolete checkhf.pl cause (at least !windows) compilers will
do a check.
I'm not 100% sure how portable __start_section, __stop_section is[1] so
I just need to write some autotools scriptz. Don't know when.
[1] sample how to use __start, __stop:
http://stackoverflow.com/questions/3808053/how-to-get-a-pointer-to-a-binary-section-in-msvc
(this is good sample for gcc/clang, I don't know how to do it properly on
MSVC).
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Taps should not use fd->flags.passed_dfilter (rtp, iax2, flow_analysis)
On Fri, Aug 16, 2013 at 07:29:17AM +0200, Anders Broman wrote: > Jakub Zawadzki skrev 2013-08-15 14:04: > > Few GTK taps are using fd->flags.passed_dfilter as information whether > > given packet is displayed, this is little broken and might not work as > > intended. > > > > [cut] > > > > but if you are doing some rtp analysis and do refiltering like: > >frame.number == 1 > >## nothing changes > > > >frame.number == 2 > >## only frame #1 shows in stream analysis > > > >frame > >## only frame #2 shows in stream analysis > > > >empty filter > >## all frames from rtp stream shows up > > > > > > I don't have any iax2 capture file but it's probably broken like above. > > > > Conversations tap and 'limit to display filter' is implemented properly > > (gratz!) > > Attaching patch based on it. > > > > I'm not doing any rtp analysis, so please advice if it's proper way. > > Thanks. > > > Looks correct to me :-) What about: > >frame.number == 1 > >## nothing changes It'll no longer work. Do we need 'limit to display filter' checkbox? ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Decompress problem if data is over multiple frame
Hi, On Thu, Aug 15, 2013 at 03:57:07PM +0200, Hardik Patel wrote: > I am creating dissector plugin. Trace which i have capture is compressed by > zlib. > > I have two option > 1)write own decompress function using zlib > 2) to use tvb_uncompress() function of wireshark > > Both have issue if compress packet is over multiple frame. > > wireshark tvb_uncompress() function work only from frame which have zlib > header which is obvious case. Nope, AFAIK gzip header is also supported :) > is there any particular method to save all these bytes in buffers till i > got complete data so i can start decompressor. Reassembly api (fragment_add, fragment_add_seq) or composite tvb use with conversations or if your protocol is running atop TCP you can use DESEGMENT_ONE_MORE_SEGMENT :) just a keywords, but hope that helps. Chers, Kuba. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Taps should not use fd->flags.passed_dfilter (rtp, iax2, flow_analysis)
Hi,
Few GTK taps are using fd->flags.passed_dfilter as information whether
given packet is displayed, this is little broken and might not work as intended.
>From grep:
./ui/gtk/rtp_analysis.c
./ui/gtk/iax2_analysis.c
./ui/gtk/flow_graph.c
flow_graph requres clicking OK to trigger graph_analysis_update()
so it doesn't change when refiltering
(but if you close file and click some packet it'll nicely crash :)).
but if you are doing some rtp analysis and do refiltering like:
frame.number == 1
## nothing changes
frame.number == 2
## only frame #1 shows in stream analysis
frame
## only frame #2 shows in stream analysis
empty filter
## all frames from rtp stream shows up
I don't have any iax2 capture file but it's probably broken like above.
Conversations tap and 'limit to display filter' is implemented properly (gratz!)
Attaching patch based on it.
I'm not doing any rtp analysis, so please advice if it's proper way.
Thanks.
diff --git a/ui/gtk/rtp_analysis.c b/ui/gtk/rtp_analysis.c
index 8f92958..fe72b66 100644
--- a/ui/gtk/rtp_analysis.c
+++ b/ui/gtk/rtp_analysis.c
@@ -314,6 +314,18 @@ rtp_reset(void *user_data_arg)
{
user_data_t *user_data = (user_data_t *)user_data_arg;
+ GString *error_string;
+ const char *filter;
+
+ filter = gtk_entry_get_text(GTK_ENTRY(main_display_filter_widget));
+
+ error_string = set_tap_dfilter(user_data_arg, filter);
+ if (error_string) {
+ simple_dialog(ESD_TYPE_ERROR, ESD_BTN_OK, "%s", error_string->str);
+ g_string_free(error_string, TRUE);
+ return;
+ }
+
user_data->forward.statinfo.first_packet= TRUE;
user_data->reversed.statinfo.first_packet = TRUE;
user_data->forward.statinfo.max_delta = 0;
@@ -492,11 +504,8 @@ rtp_packet(void *user_data_arg, packet_info *pinfo, epan_dissect_t *edt _U_, con
const struct _rtp_info *rtpinfo = (struct _rtp_info *)rtpinfo_arg;
gboolean rtp_selected = FALSE;
- /* we ignore packets that are not displayed */
- if (pinfo->fd->flags.passed_dfilter == 0)
- return 0;
/* also ignore RTP Version != 2 */
- else if (rtpinfo->info_version != 2)
+ if (rtpinfo->info_version != 2)
return 0;
/* is it the forward direction? */
else if (user_data->ssrc_fwd == rtpinfo->info_sync_src
@@ -2033,12 +2042,15 @@ static void
on_refresh_bt_clicked(GtkWidget *bt _U_, user_data_t *user_data)
{
GString *error_string;
+ const char *filter;
/* remove tap listener */
remove_tap_listener(user_data);
+ filter = gtk_entry_get_text(GTK_ENTRY(main_display_filter_widget));
+
/* register tap listener */
- error_string = register_tap_listener("rtp", user_data, NULL, 0,
+ error_string = register_tap_listener("rtp", user_data, filter, 0,
rtp_reset, rtp_packet, rtp_draw);
if (error_string != NULL) {
simple_dialog(ESD_TYPE_ERROR, ESD_BTN_OK, "%s", error_string->str);
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Enabling packet editor (was: Re: packet_win.c still broken)
On Wed, Aug 14, 2013 at 02:41:19PM +0200, Alexis La Goutte wrote: > > Hey, I use it too.I really like it option to modify and save that to file. > > It can be used to check another protocol value while writing new dissector. > > http://wiki.wireshark.org/GSoC2013 (Packet Editor) > > > > Maybe experimental options like this should be enabled in development > > release, than disabled in release if incomplete. As I know this one is not > > broken. > > > > I like the idea of Michal, to add by default packet editor and a preference > to enable the feature. > I will make more visibility to packet editor... > > I attach a serie of patch to add packet editor to the default and > preference I'm fine with these patches (why you need preference option for it?). Still we've discussed this topic already in: "[Wireshark-core] 1.6 branch" thread, and I'm afraid nothing was changed. It was fun project, I no longer need it, and I'd rather drop it rather than enable (code is not so great). We had lot (I counted 4) of GSoC students who wanted to work on packet editor stuff, maybe we pick one next year? Cheers, Kuba. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Remove hf_ variables
On Wed, Aug 14, 2013 at 09:26:17AM +0100, Graham Bloice wrote: > On 13 August 2013 17:53, Jakub Zawadzki wrote: > > > On Fri, Aug 09, 2013 at 08:31:02PM +0200, Jakub Zawadzki wrote: > > > On Wed, Aug 07, 2013 at 08:10:21PM +0200, Jakub Zawadzki wrote: > > > > I wrote some ugly gawk program for hf_ variables. > > > > > > > > Here is one + some patch for epan: > > > > http://www.wireshark.org/~darkjames/proto-new/0001-changes.txt > > > > > > > > Here is convertion of some dissectors (not quite automagic): > > > > http://www.wireshark.org/~darkjames/proto-new/0002-rewrite.txt > > > > > > > > We probably don't want this redefine macros inside proto-new.h but > > it's *much faster* > > > > to test. > > > > > > Removed in v2: > > > > > > http://www.wireshark.org/~darkjames/proto-new-v2/0001-changes.txt > > > http://www.wireshark.org/~darkjames/proto-new-v2/0002-rewrite.txt > > > > > > Changes from v1: > > > - proto_tree_add_item() now takes pointer to header_field_info *, > > >if NEW_PROTO_TREE_API NOT defined small compatilibity macro is used. > > > - convert names just to hfi_ not hfi_hf_ > > > - fix proto_get_first_protocol_field(), proto_get_next_protocol_field() > > > > Ping, any feedback? > > > It's not entirely clear to me from the thread what the current intent is. > Your current plan is just the removal of hf vars? I'm not sure what 'just' means, generally yes, but to be sure please check patches above (I'm much more fluent in C than in English ;-)). > You'll also need to update the docs, README.dissector is the most obvious, > then everyone's presentations on how to build a dissector :-) Old registration-style still works. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Interesting thing about "recent" changes in GHashTable
Hi, On Tue, Aug 13, 2013 at 06:15:28PM -0400, Evan Huus wrote: > Not worth it in my opinion unless the memory savings are significant (I > suspect they are only in the range of a few-hundred KB). Yes, something like this. Exact numbers for few: proto_names21KB3 insertions(+), 15 deletions(-) registered_dissectors 8KB 41 insertions(+), 20 deletions(-) eth_hashtable 6KB 51 insertions(+), 76 deletions(-) manuf_hashtable 262KB 64 insertions(+), 25 deletions(-) sub_dissectors 40KB 46 insertions(+), 25 deletions(-) 338 KB in total. (test patches: http://www.wireshark.org/~darkjames/ghashtable-set/) ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
