u try to contact Phil Karn? This stuff seems to be in linux kernel and I
doubt it's GPL1, moreover he has LGPL code at http://www.ka9q.net/
Didier
___
Sent via:Wireshark-dev mailing list
Archives:h
rit)...
om the second pass, but we would have to calculate in advance which
> >>> packets are visible, which may or may not be easy.
> >> Pardon my wireshark ignorance but it really look like the 2nd and the 3rd
> >> pass
ld be ok now.
>
> >When compiling wireshark it's also extract which dissectors don't call
> >subdissectors or only call them via wireshark API
>
> If this is similar to a previous patch it requres changes to many
> dissectors.
>
They was a lot of thing in this pat
don't call subdissectors and
has no interesting fields for the filter evaluation.
- set tree to NULL when calling dissectors with no 'interesting fields'. I'm
not sure this one is worth it without the AOT trans
Hi,
Le lundi 14 octobre 2013 à 10:41 +0200, Pascal Quantin a écrit :
>
> Hi Didier,
>
> this is fixed in r52597. If you spotted other regressions, please
> notify us.
thanks, a bit slow though, it's look like check_col() had its use after
all :)
Reg
than calling
dissector()
Comments?
Didier
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:w
r colinfo not null worth it? There's so many bugs, Personally I
gave up on it.
One example with tshark, without a tree tcp flags aren't set anymore in
colinfo (cf packet-tcp.c around line 4228, since
dfa2156e301539929a12dda54752c77
nfo a boolean for heuristic/non heuristic
dissector, it helps a lot for packets without leaf dissectors.
I think I also extended conversation semantic for not calling
heuristic_try in most cases.
Didier
___
Sen
Unfortunately I get the whole tree. I failed to specify that only my
> dissector's output is reported.
>
> How can I limit the output to one protocol level. As an example the TCP
> level would be great (without IP, Ethernet, Frame)?
be nice to fix
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4102
g_strlcpy doesn't work with UTF8 and these
'Pango-WARNING **: Invalid UTF-8 string passed to pango...'
are a pain.
Didier
___
Sent via:
);
> ourinternal_handle = find_dissector("ourinternal");
> }
> if (ourinternal_handle != NULL) {
> fprintf(stderr, "Setting ourinternal dissector? ");
> conversation = fi
Lua Error: [string "/tmp/eris.lua"]:307: bad argument #2 to
'append' (userdata expected, got no value)
Thanks
Didier
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/li
ray ba = g_byte_array_new();
g_byte_array_append(ba,ep_tvb_memdup(fi->ds_tvb,fi->start,fi->length),fi->length);
IMO tvb_get_ptr is fine here, data is copied in g_byte_array_append.
Didier
___
Sent via:Wiresha
Hi,
Le mardi 23 février 2010 à 14:50 -0500, Jeremy O'Brien a écrit :
> Hmm... I was trying to avoid touching any existing dissectors to allow
> my plugin to be as modular as possible. There's no other (easy) way?
a lua
s with
> > information associated with the reassembly?
A 'Reassembled by' field would be helpful when a PDU isn't fully
reassembled.
It's an issue when a heuristic dissector wrongly grab a conve
needs
some work in asn2wrs.py.
IMO not compiling this protocol or using a stub for ppc64 is an easier
option :)
Note:
I don't have a full powerpc 64bits setup thus I can only compile not
link 64 bits code.
Didier
___
Se
Hi,
Le mercredi 27 janvier 2010 à 14:56 +0100, Radek Vokál a écrit :
> On 01/27/2010 09:32 AM, didier wrote:
> > Hi,
> > Le mercredi 27 janvier 2010 à 00:54 -0700, Stephen Fisher a écrit :
> >> On Tue, Jan 26, 2010 at 06:40:38PM +0100, Radek Vokál wrote:
> >>
>
t; anyway having all of those strings handled differently.
There's a lot of stuff like:
{ "midambleAllocationMode", "rrc.midambleAllocationMode", ...
Is it possible to compress it to the pseudo code:
const foo = "rrc.midamb
Hi,
Le jeudi 14 janvier 2010 à 17:37 +1100, Ian Schorr a écrit :
> Hi Didier,
>
> On Thu, Jan 14, 2010 at 4:54 PM, didier wrote:
> > Hi,
> > The whole file is first dissected sequentially with
> > pinfo->fd->flags.visited set to FALSE.
> >
> > The mos
list tree is null when loading a
file, before it was null only with colors disable.
You can test if it's the case by setting a filter like 'frame' and
reloading the file with CTRL R.
in packet-nfs.c a lot of:
if (fitem)
looks suspicious to me as a null tree ==> proto_tre
t then you should create a new tvb.
Did you add a new data source? It might work but it won't be pretty.
>
> Somehow have to change that checksum of the frame that I am forwarding
> to the builtin dissector.
Another option would be to add a new preference to the standard
disse
amp;& tcp.port==foo'
True table
v2 tcp.port==foo S
0 unknown 0
1 unknown 2
0 unknown 0
1 unknown 2
Only have to decode packet if S == 2
Didier
___
Sent via:Wireshark-dev mailing
better way to reduce
> the size of Libwireshark dramatically (I would like it to only be a
> few MB if at all possible)
I would remove them from Makefile.common rather than Makefile.in and
rerun autogen.sh, Makefile.in is a generated file, it
are
primed, is not the case with 1.3.
Didier
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options
t; (for packet data, etc.).
A better layout between write once and read/write data may help a lot
too. It will obfuscate the code though.
Didier
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshar
Hi,
Le vendredi 09 octobre 2009 à 09:15 +0200, Erlend Hamberg a écrit :
> On Friday 9. October 2009 03.47.16 didier wrote:
> > A modified Tshark should be able to upload a capture at around 30,000
> > packets/second.
>
> Very interesting. By "uploading", I presume
files I would use MonetDB, I don't know if
using wireshark on such big data set would be useful though, at some
point more data is just noise.
Note:
A simple expression is a filter expression with only protocols or
previous expressions. ex:
llc && !arp
is a simple expression
tcp.stream
Hi,
Le mercredi 07 octobre 2009 à 13:59 +0200, Anders Broman a écrit :
> >Didier
> More or less vanilla Wireshark, no colors. Enclosed proto Hierarchy. I can't
> share this file unfortunatly. The reason why I chose it is just that it
> caused 'Out of memmory' wi
Hi,
Le jeudi 08 octobre 2009 à 09:58 -0400, Jeff Morriss a écrit :
> didier wrote:
> > But are canaries used at all? In my understanding without
> > DEBUG_INTENSE_CANARY_CHECKS they are never checked and it's unset by
> > default.
>
> Erm, emem_free_all() check
But are canaries used at all? In my understanding without
DEBUG_INTENSE_CANARY_CHECKS they are never checked and it's unset by
default.
You can try with
setenv WIRESHARK_DEBUG_SE_NO_CANARY
but first replace the padding with the right value: in emem.c
@@ -524,7 +467,7
bytes (could be 16) and we are allocating a
lot of them so yes using g_slice_new or g_malloc here make sense.
Using a g_string_chunk for frame data col_text too but it's not a
problem here loading a file doesn't initialize a lot of them.
Didier
>
> Should we have a
cket list should be as fast as the old packet list with color
disable an all columns but the frame number removed.
On the other hand your load time is really slow can you share your
wireshark profile, your disable protocols and your capture or at least
its protocol hierarchy?
Didier
___
emory usage goes up when chunks are off.)
In this case wireshark allocates a emem_chunk_t (28 bytes on a 32bits
system) for each ep/se_alloc call.
>
> Maybe Windows doesn't like big (10Mb) allocations? Another thing is
Maybe an option would be to replace it with g_malloc.
Didier
Hi,
Le lundi 05 octobre 2009 à 17:01 +0200, Håvar Aambø Fosstveit a écrit :
> Hello!
>
> We are a student group from the university of Science and Engineering in
> Norway, and are having a project on handling large data sets and specifically
What do you mean by large data s
en that might be interesting, as I know which packets are “mine” and
> if I learn later that I can decode them then I would know the frame
> numbers to re-parse.
Currently it's not possible.
Didier
>
___
Sent
ee is visible
>
> Nope. It's also used, for example, by "tshark -x", even if "-V" isn't
> specified. There may be other places where it's used as well.
Hum, does it means that all dissectors using
if (tree) {...; call_dissector(data_handle,...) }
Have
ing a filter like 'tcp' and
reloading the file (CTRL R).
We may have to re-enable tree in cf_read, there's too many bugs like
this one.
Didier
___
Sent via:Wireshark-dev mailing list
Archives:http
gt;> }
> >>> ##
> >>>
>
> Yes even "Try heuristic sub-dissectors first" preference is not
> set . Even then it decodes as RTCP & not FOO..
I guess someone h
Hi,
Le mercredi 02 septembre 2009 à 20:01 +0200, Anders Broman a écrit :
> Coould you try revision 29673 to see if "packets without color are randomly
> colorized"
> Are fixed ?
Yes it works for me n
without color are randomly colorized).
- changing to a profile with different columns doesn't work.
But it doesn't seem to dump core or leak.
Didier
___
Sent via:Wireshark-dev mailing list
Archives:
Hi,
Le mardi 01 septembre 2009 à 11:11 +0200, Anders Broman a écrit :
> Hi,
> Could startup of Wireshark be speeded up by using treads for the init
> routines in epan_init()?
Is Wireshark startup really CPU bound?
with FT_UINT.
>
> what circumstances may cause this error ??
The -1 size, with add_item it's only valid for type proto, strings, byte
and none.
Didier
___
Sent via:Wireshark-dev mailing list
Archives:
t;,
> FT_UINT8, BASE_DEC,
> "Transmit power for message in dBm",
> 0x0, NULL, HFILL }
> },
Should be
{ &hf_abc_txPower,
{ "txPower", "abc.txPower",
FT_UINT8, BASE_DEC,
NULL,0x0,
er across TCP but you get the idea.
You can do it in the get_pdu_len function, but it has other issues (like
when the actual length of the continuation is smaller than the min
length).
Didier
___
Sent via
eld2
>
> This is not possible with the current implementation.
I think you can do it with lua script, slow but doable.
Didier
>
>
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.or
Hi,
Le jeudi 20 août 2009 à 21:53 +0100, Martin Mathieson a écrit :
> expert_comp_table.c uses g_string_chunk_clear
Can you try patches in
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3929
Didier
___
Sent
i->protocol= ep_strdup(pinfo->current_proto);
to
ei->protocol= pinfo->current_proto;
because pinfo->current_proto is currently always a constant but it's not
something we can enforce. Maybe it should use a string_chunk too.
Didier
patch something
like?
- FT_UINT8, 16, NULL, 0x0, NULL, 0x000F, 0, 0, NULL, NULL }
+ FT_UINT8, 16, NULL, 0x0F, NULL, HFILL }
Didier
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wire
acket-ieee80211.c
search for try_decrypt_wep and add_new_data_source
Didier
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailm
kground: I want to trigger some actions when a packet is captured (or in
> other words: the first time it appears in the packet pane).
>
pinfo->fd->flags.visited is false the first time a packet is dissected.
Didier
ES)
368 315 MB
but there's the copy of col_expr in frame data.
And on a bigger file (doesn't load in svn Wireshark):
557 MB 1.4M packets
virt res
470MB 420MB
after sorting
600MB 518MB
Didier
___
Sent via:W
nly memory uncompress with a large files executable
though).
- faster both for filtering and when loading a file (unzip would be done
on a different core).
The drawback of course is the disk usage but it shouldn't matter for
small files and for big file wireshark is slow and next to unusa
I think. A 61Mb trace New packet list with
> patch ~11s, old WS (SVN Rev 27374) ~16s
Are you sure it's not because you've disabled coloring?
Didier
___
Sent via:Wireshark-dev mailing list
Archives:ht
t 49041 null col info
tshark: packet 74316 again null col info in print_packet()
for fuzz-2009-06-26-23834.pcap
wireshark: packet 25183 null col info
tshark: packet 55581, null col info in print_packet()
in packet-hip.c:
col
Yes false positives are a show stopper.
BTW are you still working on your SAT patch?
I did update my changes but as I wrote I'm not sure a whole SAT is
needed for only building a truth table. As a matter of fact I removed
it.
Didier
Hi,
Le jeudi 11 juin 2009 à 16:24 +0530, BANDARU, Govindarao (Govindarao) a
écrit :
> Didier,
> Thanks a lot for quick response. I will give a try now.
> Where I can see text output of flow graph? Please let me know.
Huh? Are we speaking about the same thing? Here both in 1.0 an
Didier
___
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
t; implement this in Wireshark?
With testing? At most half a day.
> One more thing is, can we save flow in a readable format (could be
> in pdf format)?
There's a text output, no idea if it's readable though :)
Didier
>
__
Hi,
Le vendredi 05 juin 2009 à 17:26 -0700, Guy Harris a écrit :
> On Jun 5, 2009, at 4:29 PM, didier wrote:
> This would presumably be combined with a complete removal of the
> col_expr field from the frame_data structure, right?
Yes absolutely but for testing purpose this patch
Le samedi 06 juin 2009 à 00:26 +0200, Sake Blok a écrit :
> On Fri, Jun 05, 2009 at 11:55:02PM +0200, didier wrote:
> > Le dimanche 31 mai 2009 à 11:56 +0200, Sake Blok a écrit :
> > > Hi Jaap (& list),
> > >
> > > As the "father" of the "co
> disable the functionality in the packet-list. Then we can decide later to
> make it either optional of write code that dynamically generate the filter
> string on use (if that is at all possible).
Anyone remember why it was changed from dynamically ge
trying to run generated executable, man pages.
- Running tshark on a mips router? I'm afraid it's hopeless, not enough
RAM.
Didier
___
Sent via:Wireshark-dev mailing list
Archives:h
Hi,
Le dimanche 17 mai 2009 à 21:27 -0600, Stephen Fisher a écrit :
> On Mon, May 18, 2009 at 12:53:52AM +0200, Stig Bj?rlykke wrote:
>
> I would like to figure out what changed so we can be sure we're
> fixing the right thing...
W
(flags&F_RESPONSE)?" response":""));
...
col_add_str(pinfo->cinfo, COL_INFO, buf);
cinfo = pinfo->cinfo;
} else {
cinfo = NULL;
}
Didier
___
Hi,
Le dimanche 10 mai 2009 à 15:22 +0200, Kovarththanan Rajaratnam a
écrit :
> Hello,
>
> didier wrote:
> > Hi,
> > Le mardi 24 mars 2009 à 19:46 +0800, yami a écrit :
> >> Hi
> >>
> >> I've tried Didier's patch in Windows (compiled in M
arantee that tvb buffer life is never greater
than 'ep' memory.
And don't forget the tvb_set_child_real_data_tvbuff() call or you leak
tvb buffer.
Didier
>
> (_AppendMultiMsg)( target, bnpLength );
> multiMsgSize = (_GetMultiMsgSize)();
>
b_set_free_cb(new_tvb, my_free);
my_free() is called when next_tvb is freed.
for example if data is a g_malloc buffer, g_free will do it.
Didier
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wir
the main tvb, mainly for house keeping (freeing and so
on):
tvb_set_child_real_data_tvbuff(tvb, next_tvb);
and then create a new data source:
add_new_data_source(pinfo, next_tvb, "my data");
Didier
___
Sent via:Wi
Hi,
Le lundi 23 mars 2009 à 20:54 +0100, Joerg Mayer a écrit :
> On Mon, Mar 23, 2009 at 06:29:11PM +0100, didier wrote:
> > There's still some small stuff which could go but It would only improve
> > wireshark speed by 20-40%, I'm not sure it's worth the time.
&g
>
> Line 1 of "packet-tipc.c" is at address 0x1590c24
> but contains no code.
>
> Am I missing something?
Did you export CFLAGS?
Another way which works here:
configure CFLAGS=g
Didier
___
Sent via:
;t generate a memory error but both the cache
and the new syntax tree nodes data point to same address and the solver
finds a match.
I don't know the proper way to fix this one, for testing I've commented
FVALUE_FREE call in dfvm_value_free()
Didier
_
s a prejudice, at first I thought that running Wireshark on
captures with millions packets was stupid, about using the right tool
and so on, but it's surprisingly useful.
Didier
___
Sent via:Wireshark-dev mailing list
A
Hi,
Le dimanche 22 mars 2009 à 02:13 +0800, yami a écrit :
> Hi Didier,
>
> Thank you for trying the patch :) and all the good comments given.
>
> I've attached a new patch to the wiki. Please see my detailed reply
> below.
>
> - If compiled w
ou apply a filter, mark all packets, maybe unmark some of them, then
reset the filter and use 'find next mark', 'find previous mark' for
moving quickly between them because what you really want it's looking at
packets just before or just after the marked ones.
--> !H1 --> H2
tcp.stream eq 2 --> H3
!(tcp.stream eq 1) && !(tcp.stream eq 2) --> H2 && !H3
may be good enough.
Didier
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wir
i.wireshark.org/Development)
Didier
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailt
e of 0.
With your protocol structure, as describe in the dissector, you can't
use tcp_dissect_pdus reliably.
It doesn't work if in the same tcp segment you have:
With size <= 4
and size > 8
For long packet y
Hi,
Le mardi 24 février 2009 à 13:54 +0100, Anders Broman a écrit :
> Hi,
> I tried reseisable=FALSE without any noticable improvment. The bug report now
> has a test file.
Where?
Thanks
Didier
___
Sent via:
able.get("eth.type")
I've never tested it with lua but it's ethertype not eth.type
> eth_table:add(18000,s4n_proto)
>
> However, i've a probleme the eth.type is no a dissector table
> therefore I don't know how to do to simply register a simple lua
> protocol to an
e preferences dialog always trigger a re-dissection
because the dialog box selects the first displayed column which emits a
"changed" signal.
Didier
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
ten time faster than
svn code, only tested on i386 and ppc.
Didier
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
set(tvb, offset, 1, 1);
> tvb_composite_append(tvb1 , tvb2);
Look at epan/dissectors/packet-rtmpt.c, it's the only dissector using
tvb_composite(). I don't know if it's working though (cf. comment in
packet-http.c).
Didier
___
Wireshark-dev m
ogress screen is moved to
> the front. I would like to get the "Expert info" screen back in front when
> rescanning is finised.
>
> Or should cf_redissect_packets(&cfile); be called before
> gtk_widget_show_all(ss->win);
Many taps use gdk_window_raise()
Didier
e);
tree = proto_item_add_subtree(simulcrypt_item, ett_foo);
proto_tree_add_item( tree, hf_simulcrypt_parameter_type, tvb, offset, 2,
FALSE );
A drawback: there's only one expand/collapse state per ett_foo
Didier
>
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
o->src, &pinfo->dst,
pinfo->ptype, pinfo->srcport, pinfo->destport, 0);
if (c == NULL) {
c = conversation_new(pinfo->fd->num, &pinfo->src, &pinfo->dst,
pinfo->ptype, pinfo->srcpor
OROUT 0xU
Didier
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
eur_dissector_add epan/dissectors/*.c
returns 69 files.
Could simple ones, like packet-tali.c or packet-pktgen.c, answer your
questions?
Didier
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev
n lint you get:
ipfd_head: always true condition.
lint can find bugs, but it has a very high rate of false positive, you
have to live with it. I thought that after the debian debacle about ssl
we should be a little wiser about that kind of spurious code
modification.
Didier
___
;
> conversation = conversation_new(...);
> conversation_add_proto_data(conversation, proto_handle, data);
> }
You must use find_conversation() first because TCP has already created
one for reassembling.
Didier
___
Wireshark-dev mailing list
Wireshark
n my Ubuntu box with:
>
> make all CC=ccc
...
> AFAICT, libtool (1.5.26-1ubuntu1) doesn't seem to invoke the given ccc
> script. Any hints?
>
Did you try:
export CC=ccc
./configure
make
Didier
___
Wireshark-dev mailin
yway, some kind of memory corruption, double check your memory
allocations, there's a least one bug in your code above: sizeof(temp_str) is
4 or 8 not STRING_BUFFER, maybe you did the same mistake elsewhere and smashed
the stack, heap, whatever.
Didier
>
_
the search routine, for which a change will be
> committed later.
I think that if it's a tcp sub dissector you also have to use a
different type, not pinfo->ptype in find_conversation/conversation_new
or you'll get the conversation created by the TCP disssector or break
various tcp
Hi,
There's something strange around line 3357 it calls proto_tree_add_xxx
functions with bp_tree before initializing it.
?
Didier
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Hi,
On Thu, 20 Dec 2007 08:18:12 -0500, Maynard, Chris wrote
> I see 221 malformed packets, not 7, using Analyze -> Expert Infos.
> Didier, you think the proposed fix for bug 1998 created a new
> problem while trying to correct another?
Yes I do, the fix add a tvb_ensure_length_r
le I ran the following commands:
>
> n22_uml ~ # mount /mnt/nfs/n22_tmp
> n22_uml ~ # ls /mnt/nfs/n22_tmp
> n22_uml ~ # umount /mnt/nfs/n22_tmp
>
http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1998 Fixed?
Didier
___
Wir
Hi,
Is there a test suite for TCP desegmentation? I've problem with:
http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1124
ie. desegmentation code only desegments the fix header part.
But I'm afraid of regressions.
Regards
Didier
___
Hi
[UTF-8?]On Sun, 2 Dec 2007 22:48:12 +0100, Stig Bjørlykke wrote
> On 2. des.. 2007, at 16.49, Didier wrote:
> > cf patch attached.
>
> Ah, I see. But I think the Protocol column is a bit harder to read
> with the filter appended like this.
I agree.
>
> I suppose
Hi,
[UTF-8?]On Fri, 30 Nov 2007 16:37:55 +0100, Stig Bjørlykke wrote
> 2007/11/29, Didier <[EMAIL PROTECTED]>:
> > The filter value somewhere in the Protocol hierarchy stat would be nice too.
>
> You should try svn r23686 or later :)
Interesting but it's not what I had i
ways the
protocol filter value.
The filter value somewhere in the Protocol hierarchy stat would be nice too.
Didier
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
KB noneDetails | Diff
Click on Details
It's on the left:
Flags:
review_for_checkin
Didier
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
1 - 100 of 139 matches
Mail list logo
