Ah, sorry. This did work.
Thanks! This is what I needed
On Tue, Apr 26, 2011 at 5:54 PM, George Nychis wrote:
> Hi Chris,
>
> Thanks a bunch for the response.
>
> I have decided to disable certain protocols using a
> ~/.wireshark/disabled_protos file (which I confirmed is being read), however
On Wed, Apr 27, 2011 at 12:30:49AM +0200, Sake Blok wrote:
> Now that this is fixed, do any of you run into other areas in
> Wireshark left that lack IPv6 support?
Just bug #5538, which states that Wireshark can't use masks in IPv6
display filters.
__
On 26 apr 2011, at 23:59, ger...@wireshark.org wrote:
> - Support for IPv6 SSL as posted by bug#3343 comment#1
Now that this is fixed, do any of you run into other areas in Wireshark left
that lack IPv6 support?
Cheers,
Sake
___
Hi Chris,
Thanks a bunch for the response.
I have decided to disable certain protocols using a
~/.wireshark/disabled_protos file (which I confirmed is being read), however
despite "smb" and other smb related protocols being in the disabled list,
dissect_smb() is still called:
#10 0x00d3386f in d
On Wed, Apr 27, 2011 at 12:29:47AM +0300, Kaul wrote:
> (is packet_info even properly memory aligned with all those 'random'
> sized fields in it?!)
Properly aligned? The compiler should do that. Optimally aligned (if
there is such a thing)? Not sure.
On Tue, Apr 26, 2011 at 9:57 PM, Chris Maynard wrote:
> George Nychis writes:
>
> > Another alternative, is to remove packet-smb* from the build.
>
> In most cases, to remove unwanted protocol dissectors from the build,
> delete the
> relevant packet-*.c files from epan/dissectors/Makefile.common
The Buildbot has detected a new failure of OSX-10.5-x86 on Wireshark
(development).
Full details are available at:
http://buildbot.wireshark.org/trunk/builders/OSX-10.5-x86/builds/2966
Buildbot URL: http://buildbot.wireshark.org/trunk/
Buildslave for this Build: osx-10.5-x86
Build Reason:
Bui
The Buildbot has detected a new failure of OSX-10.6-x64 on Wireshark
(development).
Full details are available at:
http://buildbot.wireshark.org/trunk/builders/OSX-10.6-x64/builds/2512
Buildbot URL: http://buildbot.wireshark.org/trunk/
Buildslave for this Build: osx-10.6-x64
Build Reason:
Bui
The Buildbot has detected a new failure of OSX-10.5-PowerPC on Wireshark
(development).
Full details are available at:
http://buildbot.wireshark.org/trunk/builders/OSX-10.5-PowerPC/builds/2570
Buildbot URL: http://buildbot.wireshark.org/trunk/
Buildslave for this Build: osx-10.5-ppc
Build Reas
The Buildbot has detected a new failure of Visual-Studio-Code-Analysis on
Wireshark (development).
Full details are available at:
http://buildbot.wireshark.org/trunk/builders/Visual-Studio-Code-Analysis/builds/562
Buildbot URL: http://buildbot.wireshark.org/trunk/
Buildslave for this Build: vs
On Tue, Apr 26, 2011 at 08:25:48PM +0100, Tyson Key wrote:
> It's very rough; and I don't know what the best way to deal with
> displaying and manipulating strings of an unknown length is -
Looking at the http dissector may be of help here.
> although it nicely filled a need that I had at the t
Hi,
I'm trying to fix gcc 4.6's 'variable set but not used' errors that
wireshark compilation currently produces, via
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5858 .
I've already fixed quite a few of them. Most are trivial, those that weren't
I've remarked in the attachment comments.
-
Hi folks,
I've just stumbled upon an old, experimental plug-in dissector that I wrote
to dissect "raw" AT/Hayes commands in USB traces, during the process of
working on another, otherwise unrelated dissector. (See
https://bitbucket.org/vmlemon/usb_isi_dissector_for_wireshark/src/eec3bf16fedf/at-ha
George Nychis writes:
> Another alternative, is to remove packet-smb* from the build.
In most cases, to remove unwanted protocol dissectors from the build, delete the
relevant packet-*.c files from epan/dissectors/Makefile.common's DISSECTOR_SRC.
Alternatively, you could just disable those prot
On Apr 26, 2011, at 7:03 PM, Guy Harris wrote:
>
> On Apr 26, 2011, at 1:12 AM, Michael Tüxen wrote:
>
>> The fields in the packet are 4 byte aligned. But if the whole structure
>> might not...
>> So should we copy them?
>
> ...or fetch them with pntohl().
>
> Where are the contents of the st
Jaap Keuter skrev 2011-04-26 18:53:
Hi,
"Deprecated" as in "not recommended, but still possible, but maybe
dropped in the future".
I'll dissect that for you:
"not recommended": Using this feature is usually an indication of poor
design.
Using a generated field might be a better design.
/And
Hi all,
I am looking for the cleanest way to remove or unregister a set of
dissectors from libwireshark. When using libwireshark, I register using:
epan_init(register_all_protocols, register_all_protocol_handoffs, NULL,
NULL,
failure_message, open_failure_message, read_failure_messa
On Apr 26, 2011, at 1:12 AM, Michael Tüxen wrote:
> The fields in the packet are 4 byte aligned. But if the whole structure might
> not...
> So should we copy them?
...or fetch them with pntohl().
Where are the contents of the structure coming from? If they're coming from
the raw packet data
Hi,
"Deprecated" as in "not recommended, but still possible, but maybe dropped in
the future".
I'll dissect that for you:
"not recommended": Using this feature is usually an indication of poor design.
Now, exceptions make the rule, therefore very common abstractions, like
'ip.addr' and 'tcp.p
But I'm not sure this is the right way to fix this. Can someone comment ?
Thanks,
Pascal.
I've copied the above over to Bug #5855 since your suggested fix also
seems to address recent Buildbot fuzz-test crashes.
Thanks for the report and analysis.
https://bugs.wireshark.org/bugzilla/show_
Chris Maynard writes:
> ... but speaking of nr ... isn't it being used uninitialized?
Nevermind.
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wi
Michael Tüxen writes:
> > It seems to be less readable version of:
> > dup_list = (guint32 *) &sack_header->gaps[nr];
> This code should also point to the right place in memory, assuming
> the correct alignment. dup_list is 4 byte aligned if and only if
> sack_header is.
It's definitely nicer .
On Apr 26, 2011, at 2:44 PM, Jakub Zawadzki wrote:
> On Mon, Apr 25, 2011 at 03:02:18PM -0600, Stephen Fisher wrote:
>> dup_list = (guint32 *)(((char
>> *)&sack_header->nr_of_dups)+sizeof(guint16)+(nr*sizeof(struct gaps)));
>
> It seems to be less readable version of:
> dup_list = (guint32 *) &
On Mon, Apr 25, 2011 at 03:02:18PM -0600, Stephen Fisher wrote:
> dup_list = (guint32 *)(((char
> *)&sack_header->nr_of_dups)+sizeof(guint16)+(nr*sizeof(struct gaps)));
It seems to be less readable version of:
dup_list = (guint32 *) &sack_header->gaps[nr];
(At least on amd64 printed offsets:
Michael Tüxen writes:
> >> dup_list = (guint32 *)((char *)sack_header + 16 + (nr*sizeof(struct gaps)))
> >
> > Clang likes something that doesn't involve casting a "char *", which is not
guaranteed to contain an
> address that's 4-byte aligned, to a "guint32 *", which is a pointer that's
suppose
Hi,
with revision 36849, when I call tshark to decode in verbose mode a pcap
file containing a single packet I get the following backtrace:
tshark -r temp.pcap -V
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb571c8e0 (LWP 11951)]
packet_range_init (range=0xbfd9f550
On Apr 26, 2011, at 6:23 AM, Guy Harris wrote:
>
> On Apr 25, 2011, at 3:01 PM, Michael Tüxen wrote:
>
>> dup_list = (guint32 *)((char *)sack_header + 16 + (nr * sizeof(struct gaps)))
>
> Clang likes something that doesn't involve casting a "char *", which is not
> guaranteed to contain an add
The Buildbot has detected a new failure of OSX-10.5-PowerPC on Wireshark
(development).
Full details are available at:
http://buildbot.wireshark.org/trunk/builders/OSX-10.5-PowerPC/builds/2565
Buildbot URL: http://buildbot.wireshark.org/trunk/
Buildslave for this Build: osx-10.5-ppc
Build Reas
The Buildbot has detected a new failure of Windows-7-x64 on Wireshark
(development).
Full details are available at:
http://buildbot.wireshark.org/trunk/builders/Windows-7-x64/builds/1654
Buildbot URL: http://buildbot.wireshark.org/trunk/
Buildslave for this Build: windows-7-x64
Build Reason:
The Buildbot has detected a new failure of Visual-Studio-Code-Analysis on
Wireshark (development).
Full details are available at:
http://buildbot.wireshark.org/trunk/builders/Visual-Studio-Code-Analysis/builds/557
Buildbot URL: http://buildbot.wireshark.org/trunk/
Buildslave for this Build: vs
The Buildbot has detected a new failure of OSX-10.6-x64 on Wireshark
(development).
Full details are available at:
http://buildbot.wireshark.org/trunk/builders/OSX-10.6-x64/builds/2507
Buildbot URL: http://buildbot.wireshark.org/trunk/
Buildslave for this Build: osx-10.6-x64
Build Reason:
Bui
The Buildbot has detected a new failure of OSX-10.5-x86 on Wireshark
(development).
Full details are available at:
http://buildbot.wireshark.org/trunk/builders/OSX-10.5-x86/builds/2961
Buildbot URL: http://buildbot.wireshark.org/trunk/
Buildslave for this Build: osx-10.5-x86
Build Reason:
Bui
32 matches
Mail list logo
