On May 12, 2017, at 1:38 AM, Pavel Strnad wrote:
> I am using latest build from master branch.
What is the last commit to the master branch in your tree/repository?
Does it have these changes:
635ae3d147ab053deda41ae0e37341b75d2b21e0
f3098fb28237e21c91ea4fcd8e918c9a2528c965
I
On Apr 30, 2017, at 6:22 PM, Jeff Morriss wrote:
> On 04/30/2017 12:34 PM, Guy Harris wrote:
>> On Apr 30, 2017, at 3:26 AM, Peter Wu wrote:
>>> For the Debian (and Cygwin/Windows) setup, installation of said file is
>>> specified (see for example the file li
On Apr 30, 2017, at 3:26 AM, Peter Wu wrote:
> For the Debian (and Cygwin/Windows) setup, installation of said file is
> specified (see for example the file list in the suggested package:
> https://packages.debian.org/jessie/all/docbook-xml/filelist).
>
> If this is missing in the macOS instru
On Apr 29, 2017, at 4:37 PM, Jaap Keuter wrote:
> Well, the local resource is the relevant file already installed on the system
> on which the toolchain runs.
This appears to be making an assumption that the relevant file is, in fact,
already installed on the system on which the toolchain runs
On Apr 29, 2017, at 1:56 AM, Jaap Keuter wrote:
> This fails when there’s no catalog to map the URL to a local resource.
What is a "local resource" in this context? Why is there a need to map it to a
local resource, rather than just reading it from the URL in question?
Removing --nonet seems
docbook/Makefile.am says
SINGLE_XSLTPROC_ARGS = \
--nonet
http://docbook.sourceforge.net/release/xsl/current/html/docbook.xsl
CHUNKED_XSLTPROC_ARGS = \
--nonet
http://docbook.sourceforge.net/release/xsl/current/html/chunk.xsl
which seems to say "
On Apr 26, 2017, at 6:50 AM, Levente Mészáros
wrote:
> I have a PCAP file which contains a fragmented 802.11 A-MSDU. At the last
> frame where reassembly happens, Wireshark tells me: Malformed Packet
> (Exception occured). After analyzing the issue carefully, I came to the
> conclusion that t
Savvius comparing their Omnipeek with Wireshark:
https://www.youtube.com/playlist?list=PLxEQt70GGwsj5ep2-ZAicpK7viy_u0bBI
I haven't watched them yet, but it'd be interesting to see if it suggests any
improvements to Wireshark.
_
The Clang project home page:
https://clang.llvm.org
links to something called the "User’s Manual":
https://clang.llvm.org/docs/UsersManual.html
but that manual, unlike the GCC manuals, does not, for example, document all
the command-line options.
If, however, you go to
On Apr 21, 2017, at 8:50 PM, ajay saxena wrote:
> Here is the verbose output from that compile
>
> Ajays-MacBook-Pro:scripts ajasaxen$ gcc -v importtest.c -o importtest
> Apple LLVM version 8.1.0 (clang-802.0.42)
> Target: x86_64-apple-darwin16.5.0
> Thread model: posix
> InstalledDir:
> /Appli
On Apr 21, 2017, at 8:04 PM, ajay saxena wrote:
> This is what i get for gcc --version
>
> Ajays-MacBook-Pro:wireshark ajasaxen$ gcc --version
> Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr
> --with-gxx-include-dir=/usr/include/c++/4.2.1
> Apple LLVM version 8.1.0 (c
On Apr 21, 2017, at 7:33 PM, ajay saxena wrote:
> Though the compile failed at a different file
>
> addr_resolv.c:91:11: fatal error: 'ares.h' file not found
> # include
So it's failing for files in the epan directory, not just for files in
epan/dissectors.
> and this file too is present in
On Apr 21, 2017, at 2:33 PM, ajay saxena wrote:
> Also cmake on the same source works, I would assume that it reads the header
> files from same locations unless it uses a fundamentally different resolution
> mechanism.
In both build processes, the resolution mechanism is in clang; the differe
On Apr 21, 2017, at 2:11 PM, ajay saxena wrote:
> the LIBGEOIP_CFLAGS is in both though.
And it's empty in both, too.
But that shouldn't matter, as the compiler should look in /usr/local/include.
> Do files in epan directory import GeoIP too?
Yes.
_
On Apr 21, 2017, at 1:47 PM, ajay saxena wrote:
> So i added the include lua directive at the top of the file and now i get the
> error for lua
>
> packet-ip.c:27:10: fatal error: 'lua.h' file not found
> #include
> ^
...which works just fine for files in the epan directory, but not
What happens if you add a
#include
header line to epan/dissectors/packet-ip.c, and try recompiling?
___
Sent via:Wireshark-dev mailing list
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe:
On Apr 21, 2017, at 12:33 PM, ajay saxena wrote:
> Below is the output from /usr/local/include
What do
ls -l /usr/local/include/lua.h
ls /usr/local/opt
print?
___
Sent via:Wireshark-dev mailing list
A
On Apr 21, 2017, at 12:18 PM, ajay saxena wrote:
> The compile fails with the same message even after I rename the existing sym
> link and phyiscally copy the file to my usr/local/include folder.
OK, you can put the symlink back.
What does "ls /usr/local/include" print?
___
On Apr 21, 2017, at 11:37 AM, ajay saxena wrote:
> I have attached with this mail, the Makefile present in
> epan/dissectors/Makefile
>
> The output of clang --version is
>
> Ajays-MacBook-Pro:dissectors ajasaxen$ clang --version
> Apple LLVM version 8.1.0 (clang-802.0.42)
> Target: x86_64-ap
On Apr 21, 2017, at 11:29 AM, ajay saxena wrote:
> This is what is get on running head /usr/local/include/GeoIP.h
>
>
> Ajays-MacBook-Pro:~ ajasaxen$ head /usr/local/include/GeoIP.h
> /* -*- Mode: C; indent-tabs-mode: t; c-basic-offset: 2; tab-width: 2 -*- */
> /* GeoIP.h
> *
> * Copyright (
On Apr 21, 2017, at 11:22 AM, ajay saxena wrote:
> /usr/local/Cellar/geoip/1.6.9 is the location of GeoIP library
> /usr/local/Cellar/geoip/1.6.9/include is the location of GeoIP.h
>
> There is a symbolic link to GeoIP.h present in my /usr/local/include
>
> Ajays-MacBook-Pro:include ajasaxen$ p
On Apr 21, 2017, at 11:01 AM, ajay saxena wrote:
> I took the latest source from code.wireshark.org and on compiling I ran into
> GeoIP.h error
>
> packet-ip.c:64:10: fatal error: 'GeoIP.h' file not found
> #include
> ^
Where is GeoIP.h located? Where is the GeoIP library located?
On Apr 21, 2017, at 10:07 AM, ajay saxena wrote:
> The commits that you've referred to,
>
> 9e4c018e08d5a657f85f0cde0607db0a6d25ddf4
> 2c52d954d5713be1b809c3b668b0353d2b355c16
>
> Are they present in the master branch on github? I cant seem to find them in
> the latest pull from github
The *o
On Apr 21, 2017, at 5:23 AM, ajay saxena wrote:
> Thanks for replying. I used cmake and it worked. I found out that i had to
> use cmake from a page on wiki.wireshark.com. I think it might be a good idea
> to include this information in README.macos file.
1) No, this is not a macOS issue. It'
On Apr 20, 2017, at 5:03 AM, Pascal Quantin wrote:
> This kind of warnings is highly dependent on the compiler version used.
> That's why it was not spotted so far, and why you are the first one to report
> the issue (for example I'm using gcc 6.3.1 and I do not have this warning).
What a mess
On Apr 20, 2017, at 5:05 AM, Pascal Quantin wrote:
> Short answer: it will not as it will create other errors:
But "const char *volatile exp_pdu_filename = NULL" should work - it's not what
exp_pdu_filename points to that needs to be made volatile, it's the pointer
*itself* that needs to be m
On Apr 19, 2017, at 5:46 AM, Alexander Adolf
wrote:
> I have used ASN.1 in projects, and I would fully support Pascal's
> recommendation that it doesn't seem the best choice for Wireshark.
It's the best choice for protocols specified in ASN.1 and using BER or PER.
Unless we add ECN support, i
On Apr 19, 2017, at 2:27 AM, Ahmad Fatoum wrote:
> • ASN.1: asn2wrs, part of Wireshark and supports packed encoding rules (PER),
> but I believe it's not possible to decode an arbitrary non-ASN.1 encoded
> protocol [1]. Is that right?
ASN.1 doesn't specify encoding, just the "abstract syntax".
On Apr 19, 2017, at 4:47 AM, Roland Knall wrote:
> Generally speaking we can divide new protocol languages in two different
> classes:
>
> - interpreting ones
> - compiled ones
>
> The interpreting class has LUA and wsgd as representative. They have their
> benefits, but I do not really like
On Apr 10, 2017, at 3:19 PM, Guy Harris wrote:
> Would a more descriptive name for it be something such as BASE_SPECIAL_VALS?
OK, I've changed the name to BASE_SPECIAL_VALS.
___
Sent via:Wireshark-dev mail
On Apr 14, 2017, at 5:18 PM, Richard Sharpe wrote:
> I was trying to use editcap (2.3.0) on a RHEL 7.2 system to chop a
> large packet capture up into smaller pieces:
>
> --
> editcap -rv ~/tcpdump_dme_pdfs-1.pcap ~/tcpdump_dme_pdfs-1-2.pcap 1-725000
> File /home/rsharpe/tcpdump_
On Apr 14, 2017, at 4:26 PM, Michael Mann wrote:
> This is an interesting problem because I'm not sure where the "data
> crunching" should really be done (GUI vs dissector).
By which you presumably mean "UI code of some sort vs. dissector", because...
> For statistics dialogs, I think more dat
On Apr 14, 2017, at 2:13 PM, Guy Harris wrote:
> On Apr 14, 2017, at 2:02 PM, Simon Barber wrote:
>
>> The timeline needs to know whether every packet includes timing information.
>> If not, the timeline should be hidden. This is only determined after all the
>> pac
On Apr 14, 2017, at 2:02 PM, Simon Barber wrote:
> The timeline needs to know whether every packet includes timing information.
> If not, the timeline should be hidden. This is only determined after all the
> packets have been through a first dissection pass.
Then there needs to be a mechanism
On Apr 14, 2017, at 12:41 PM, Guy Harris wrote:
> On Apr 14, 2017, at 3:41 AM, Paul Offord wrote:
>
>> I need some advice. I’m debugging a problem with a dissector I’ve written.
>> Tshark fails with:
>> … \epan\prefs.c:414:prefs_register_module_or_s
On Apr 14, 2017, at 3:41 AM, Paul Offord wrote:
> I need some advice. I’m debugging a problem with a dissector I’ve written.
> Tshark fails with:
> … \epan\prefs.c:414:prefs_register_module_or_subtree: assertion failed:
> (g_ascii_islower(c) || g_ascii_isdigit(c) || c == '_' || c == '-' || c
On Apr 13, 2017, at 4:40 PM, Simon Barber wrote:
> I ask because I am working out how to connect the wlan_radio dissector with
> the wireless timeline UI code.
The answer to "how do I connect the XXX dissector with the YYY UI code?" is
"very indirectly", as in "the XXX dissector is not guarant
On Apr 13, 2017, at 10:52 AM, Simon Barber wrote:
> Why are they loosely coupled?
In theory, libwireshark could be used in a program that doesn't have a "capture
file" from which the packets come.
___
Sent via:Wireshark
On Apr 11, 2017, at 10:43 PM, Paul Offord wrote:
> Nice. I'll take a look.
I've checked in some additional changes; with those changes, at least with one
SMB file I have, if I enable TRANSUM, Wireshark, and TShark when run in 2-pass
mode, produce the same output.
_
On Apr 11, 2017, at 12:13 AM, Guy Harris wrote:
> On Apr 10, 2017, at 11:57 PM, Paul Offord wrote:
>
>> OK - So just to summarize, we need to:
>>
>> • Short Term - Add a flag somewhere that can be set by a dissector,
>> post-dissector or tap to request th
On Apr 11, 2017, at 7:22 AM, Pascal Quantin wrote:
> As stated in
> https://www.wireshark.org/docs/wsdg_html_chunked/ChSrcBuildFirstTime.html#_building_on_unix,
> when using autofoo you are supposed to run ./autogen.sh so as to generate
> ./configure
...if you're building from a Git checkout
On Apr 10, 2017, at 11:57 PM, Paul Offord wrote:
> OK - So just to summarize, we need to:
>
> • Short Term - Add a flag somewhere that can be set by a dissector,
> post-dissector or tap to request that a proto_tree is produced on the first
> pass
> • Long Term – Add a facility tha
Currently, for Wireshark developer documentation, we have:
the Wireshark Developer's Guide at
https://www.wireshark.org/docs/wsdg_html_chunked/index.html
a bunch of README files in the doc directory of the source code at
https://code.wireshark.or
On Apr 10, 2017, at 3:04 PM, Paul Offord wrote:
>> If a tree isn't being generated, because it isn't necessary (e.g., if the
>> code calling the dissectors is only trying to get the column contents)
>> there's presumably no need for TRANSUM - or any other dissector or
>> post-dissector - to ad
On Apr 10, 2017, at 1:31 PM, Michael Mann (Code Review)
wrote:
> Michael Mann has submitted this change and it was merged.
>
> Change subject: Add support for BASE_VALS_NO_UNKNOWN
> ..
>
>
> Add support for BASE_VALS_NO_UNKNO
On Apr 10, 2017, at 12:30 AM, Paul Offord wrote:
>> So would you need the full protocol tree *every* time the packet is
>> dissected, or just the *first* time (meaning you'd save the results of the
>> first-pass processing and not require it later)?
>
> TRANSUM only needs the values in the fir
On Apr 9, 2017, at 10:37 PM, Paul Offord wrote:
> Ah that was going to be my next question :-)
>
> Any ideas?
Given that there are no such APIs, one would have to be added and, if we're
going to be adding APIs, an API by which a post-dissector can specify that, at
least on the first pass thr
On Apr 9, 2017, at 2:08 PM, Paul Offord wrote:
> When running tshark.
And what mechanism do you propose to use to determine whether it's running in
Wireshark or TShark?
___
Sent via:Wireshark-dev mailing list
Archives:
On Apr 9, 2017, at 1:07 PM, Paul Offord wrote:
> So if I add code to TRANSUM so that it only registers itself when running
> with Wireshark,
"when running with Wireshark" as opposed to what?
___
Sent via:Wireshark-dev
On Apr 9, 2017, at 12:48 PM, Paul Offord wrote:
> As making the code consistent has been rejected and the tap idea won’t work,
> where do we go from here?
As somebody said:
> We might also want a way to have taps/"post-"dissectors that act as
> extensions to particular protocol dissectors -
On Mar 29, 2017, at 2:04 PM, Joerg Mayer wrote:
> does HAVE_REMOTE imply that libpcap supports pcap_create nowadays? If so, it
> would
> allow some nice cleanups ;)
On Windows, where we do checks at run time (as we load WinPcap dynamically) as
well as compile time, older versions of WinPcap ha
On Mar 27, 2017, at 1:14 PM, Guy Harris wrote:
> Currently, with that fix, I get results like
>
> $ time ./tshark -r /tmp/nothing.pcap
>
> real0m1.407s
> user0m0.312s
> sys 0m0.676s
>
> with the extcap directory in place and results like
>
> $ t
On Mar 26, 2017, at 11:30 PM, Michał Łabędzki
wrote:
> Could you check if any of extcap binaries generates that delay?
A lot of the delay comes from extcap *non*-binaries; the code that scans the
extcap directory tried running *everything* it finds there, except for "." and
"..", and, if you'
$ time ./tshark -r /tmp/nothing.pcap# reading an empty pcap file
# with all the extcap binaries present
real0m4.089s
user0m0.694s
sys 0m2.637s
$ time ./tshark -r /tmp/nothing.pcap# reading the same empty pcap file
On Mar 24, 2017, at 4:21 PM, Simon Barber wrote:
> My build produced with make dmg_package seem to produce something that
> requires Mac OS Sierra to install. (I am building on Mac OS Sierra). How can
> I generate a package that will install on something older?
If you're using autotools, try r
On Mar 24, 2017, at 4:11 PM, Simon Barber wrote:
> When loading a large file (0.5M packets) with a large single TCP stream in
> it, wireshark gets very slow. I did some profiling and found 90% of the CPU
> time was spent in epan/reassemble.c LINK_FRAG() - scanning through a long
> singly linke
On Mar 20, 2017, at 5:56 PM, f1rstango wrote:
> Process: Installer [4395]
> Path:
> /System/Library/CoreServices/Installer.app/Contents/MacOS/Installer
> Identifier: com.apple.installer
> Version: ???
...
> Application Specific Information:
> dyld: launc
> On Mar 18, 2017, at 7:26 PM, Michael Mann (Code Review)
> wrote:
>
> Michael Mann has posted comments on this change.
>
> Change subject: TLS13: add certificate_authorities (47) dissection for draft
> -19
> ..
>
>
> Patch
On Feb 23, 2017, at 1:21 PM, Peter Wu wrote:
> Validation of the protocol fields (like checksums) can be done without
> external input and would be nice. On violation, these could add "expert
> info" to the tree.
>
> But for Authorization digests in SIP, this would require external input
> (cred
On Feb 23, 2017, at 11:56 AM, Erik de Jong wrote:
> During my day job I have noticed that sometimes combinations of certain
> platforms have trouble dealing with SIP digest authorization. Reasons for
> this range from bugs in the SIP stack to wrong escapes for special characters
> in configura
On Feb 22, 2017, at 7:30 AM, João Valverde
wrote:
> Maybe this will do: https://code.wireshark.org/review/#/c/20246/2
That (using a #define to hide the call to free(), by making it look like a call
to a routine with a different name) is probably the best we can do.
They (MaxMind) might want t
On Feb 14, 2017, at 1:02 AM, Paul Offord wrote:
> There definitely is a performance impact when you generate the protocol tree
> in the first pass, probably 33% longer to load.
>
> Anyway, I have a 23-hour plane journey tomorrow so I'll have a crack at
> rewriting as a TAP.
Rewriting it as a
On Feb 13, 2017, at 10:00 AM, Guy Harris wrote:
> On Feb 12, 2017, at 11:40 PM, Paul Offord wrote:
>
>> I'll accept whatever strategy there is for taps vs. dissectors. A few
>> points:
>>
>> * TRANSUM can only work if it is able to calculate values based
On Feb 13, 2017, at 4:53 PM, Joerg Mayer wrote:
> To me it looks like HAVE_LIBPCAP would be a candidate to solve somehow, as it
> is
> regularly involved when compiles break without this define. Would it maybe
> make sense
> so include a dummy version inside Wireshark that basically does (mostl
On Feb 12, 2017, at 11:40 PM, Paul Offord wrote:
> I'll accept whatever strategy there is for taps vs. dissectors. A few points:
>
> * TRANSUM can only work if it is able to calculate values based on other
> dissected values (such as smb2.msg_id), so provided the dissected values are
> availa
The underlying problem here appears to be that the TRANSUM post-dissector is
not only adding stuff to the protocol tree, which obviously doesn't need to be
done if there is no protocol tree, but is also doing *analysis* of the packet
information.
The latter of those should *not* be done in a di
On Feb 10, 2017, at 12:15 AM, Paul Offord wrote:
> It's normal for a dissector to be called with a NULL proto_tree pointer on
> the first pass *unless* a tap has been registered.
Actually, it's currently normal, in TShark, if you're doing two-pass
processing, for taps not to be called on the f
On Feb 11, 2017, at 1:57 PM, Bálint Réczey wrote:
> +1 for going without a new layer of indirections.
> Making libgcrypt mandatory is easy and every level of indirection make
> understanding the code harder which is a source of bugs.
+1
Enough places in Wireshark use it, and there will probably
On Feb 8, 2017, at 3:18 PM, Peter Wu wrote:
> On Wed, Feb 08, 2017 at 10:51:29AM -0800, Guy Harris wrote:
>> On Feb 8, 2017, at 5:40 AM, Peter Wu wrote:
>>
>>> I did not expect Libgcrypt to consume entropy when it is just doing
>>> decryption.
>>
>&
On Feb 10, 2017, at 11:58 AM, Michael Mann wrote:
> (git review may work, but I've never tried it outside of master branch)
I have, and it works, at least for me.
___
Sent via:Wireshark-dev mailing list
Archives:h
On Feb 10, 2017, at 9:17 AM, Paul Offord wrote:
> If I want to submit a fix for a bug in 2.2.4, do I switch to the master
> branch and then push the fix? Or do I change to master-2.2.4 branch, apply
> the fix and push?
Is this a bug that's in the master branch *and* the 2.2.x branch, or is it
On Feb 8, 2017, at 5:40 AM, Peter Wu wrote:
> I did not expect Libgcrypt to consume entropy when it is just doing
> decryption.
I'm concerned with consuming CPU and wall-clock time - i.e., slowing *shark
startup - not entropy.
On Feb 6, 2017, at 3:17 PM, João Valverde
wrote:
> None from me but can we use Nettle instead? Any reason not to? Word on the
> street is that it is more pleasant to work with than gcrypt.
Which, if any, of those libraries can be prevented from wasting Wireshark's
time by telling them not to
On Feb 5, 2017, at 10:21 AM, Paul Offord wrote:
> I need some guidance on the time zone settings in a PCAP-NG file.
Are you referring to the if_tzone option in the Interface Description block,
which:
1) is specified so vaguely as to make it not actually *usable* - to
quote the curren
On Feb 1, 2017, at 8:03 AM, Anders Broman wrote:
> C:\Development\wireshark\sharkd_daemon.c(167): warning C4244:
> 'return': conversion from 'SOCKET' to 'int', possible loss of data
> [C:\Development\wsbuild-gpl\sharkd.vcxproj]
> C:\Development\wireshark\sharkd_daemon.c(245):
On Jan 19, 2017, at 2:24 AM, Lu, Jed wrote:
> I’m running into the exact same issue of
> https://www.wireshark.org/lists/wireshark-dev/201608/msg00196.html ,
> wondering is there a solution already?
No, because the person who sent that message didn't bother sending the
top-level Makefile in
On Jan 24, 2017, at 9:51 AM, Juan Jose Martin Carrascosa wrote:
> I would like to write a new GUI to show nicely the information obtained from
> the RTPS dissector. Can Wireshark help with that?
There is no provision in Wireshark for showing the raw dissection result (the
protocol tree) differ
On Jan 12, 2017, at 3:00 PM, Richard Sharpe wrote:
> In packet-rpc.c we see this:
>
>/*
> * Don't call any subdissector if we have no more date to dissect.
> */
>if (tvb_reported_length_remaining(tvb, offset) == 0) {
>return TRUE;
>}
>
> H
On Jan 9, 2017, at 5:54 AM, Jirka Novak wrote:
> CCLD tshark
> ui/libui.a(rtp_stream.o): In function `register_tap_listener_rtpstream':
> wireshark-git/ui/rtp_stream.c:424: undefined reference to `simple_dialog'
> ui/libui.a(rtp_stream.o): In function `rtpstream_scan':
> wireshark-git/ui/rtp
On Jan 8, 2017, at 10:18 AM, Francesco Fondelli
wrote:
> point 3 and probably point 4, are too risky. If we go against the best
> current practice (RFC 4928, BCP 128) we need a very-very strong
> indication that the following data is not IP. I agree on everything
> else.
We need to fix bug 1330
On Jan 7, 2017, at 9:39 AM, Jaap Keuter wrote:
> There has been a steady stream of MPLS PW related comments and bugs over time,
> and things haven't improved enough, apparently. This text tries to give some
> insight in the issues so that possible solutions cover all cases involved.
I'll start h
On Jan 7, 2017, at 1:15 PM, Francesco Fondelli
wrote:
> the pw_eth_heuristic is too strong, it does not take into
> consideration locally-assigned MAC addresses and multicast (as noted
> in some bugs by Guy Harris and Michael Mann). Patches are welcome :-)
The heuristic us
On Jan 1, 2017, at 6:13 PM, Michael Mann wrote:
> I really like the flexibility and power that the current dissector table API
> provides. The one small shortcoming is that a "protocol" needs to be
> provided when adding a dissection function to a dissector table. And not all
> dissection fu
On Jan 1, 2017, at 11:39 PM, Michal Labedzki wrote:
> On 2 January 2017 at 03:13, Michael Mann wrote:
>
>> To me, pinos don't have the same capabilities as real protocols. They don't
>> have hf_ fields or heuristic dissection functions associated with them.
>> ...
>> The last example I have
On Jan 3, 2017, at 12:26 PM, Alexis La Goutte wrote:
> Yes, i look like there is a issue for get oui(.txt) database on ieee website
>
> There is a guard ( https://code.wireshark.org/review/18030 ) but only on
> master...
I backported all the changes to manuf.tmpl, wka.tmpl, and tools/make-manu
On Dec 31, 2016, at 11:08 AM, Thomas Wiens wrote:
> I was searching for the problem of displaying time zone names with
> german umlauts, and found that there is an exististing bug
> report (Bug 11785).
>
> I found that undefining HAVE_TZNAME so that the utf8 conversion in
> get_zonename (to_str.
On Dec 24, 2016, at 2:47 PM, Michael Mann wrote:
> We have 4 post-dissectors in the current source (mate, transom, snort, prp)
> and only mate defaults to being enabled (based on quick grep of API calls, it
> may be smart enough to be "disabled" if there is no configuration).
Presumably meanin
On Dec 22, 2016, at 4:29 PM, Chris Brandson wrote:
> It appears to be impossible to use external tools such as pyshark to extract
> field information from many of the fields in a ZigBee packet because many of
> the abbrev fields of the hf_register_info entries for the ZigBee dissectors
> more
On Dec 21, 2016, at 4:38 AM, Moshe wrote:
> I apologize for my lack of clarity. Peter is correct, I am interested in
> fuzzing dissectors.
>
> My plan is to have the sequence of raw bytes represent a pcap file.
I.e., represent a sequence of packets (of a particular type), rather than
represen
On Dec 21, 2016, at 2:12 AM, Peter Wu wrote:
> From the efforts that I have seen, Moshe seems to be targeting the
> dissectors functions. Since these may appear over the network, it is
> probably one of the more interesting parts to tackle first.
Then I'm not sure how well
> The second step is
On Dec 20, 2016, at 8:31 PM, Moshe wrote:
> I've been working on adding Wireshark to Google's oss-fuzz project
What do you mean by "Wireshark"?
There are at least two parts of Wireshark that deal with externally-supplied
data and can be fuzz-tested:
1) the libwiretap library, which re
On Dec 19, 2016, at 12:38 PM, Guy Harris wrote:
> On Dec 19, 2016, at 9:40 AM, Jeff Morriss wrote:
>
>> BTW, it appears extcap requires glib 2.26 (for GTimeZone) but configure.ac
>> still says we only require 2.22. Time for a version bump?
>
> So why do we need GTim
On Dec 19, 2016, at 9:40 AM, Jeff Morriss wrote:
> BTW, it appears extcap requires glib 2.26 (for GTimeZone) but configure.ac
> still says we only require 2.22. Time for a version bump?
So why do we need GTimeZone? It's required to show the current time and date
as UTC, if *that's* what we'r
On Dec 11, 2016, at 11:18 PM, Michal Labedzki wrote:
> Good idea.
> I have similar problem with Bluetooth protocols. There is a lot of something
> like that:
> "Latency = N * 0.625 ms (1 Baseband slot)"
I.e., the value of the field is the number of baseband slots, and the latency,
in millisec
On Nov 19, 2016, at 8:58 AM, Jaap Keuter wrote:
> On 19-11-16 16:41, Dmitry Lazurkin wrote:
>> Hello.
>>
>> Function proto_item_set_len modifies fi->value.value.bytes->len, but
>> proto_item_set_end doesn't make same thing. Is it bug?
>
> An omission maybe. Guy, Stig, Martin, care to comment?
On Nov 11, 2016, at 1:59 AM, Anders Broman wrote:
> https://wiki.wireshark.org/Development/LifeCycle
>
> Version Stable Release Date End of LifeNotes
>
> 1.8 June 21, 2012 June 21, 2014 Last release to support
> OS X on PPC
>
> 1.8 vent end-of-life June 21, 201
On Nov 4, 2016, at 7:21 PM, Richard Sharpe wrote:
> I find myself wanting to search for packets where nfs.offset3 is in
> the range of 100,000 and 200,000 say.
>
> However, a simple query has not done it, since it seems to have found
> all the packets in the capture.
nfs.offset3 >= 10 && nf
On Oct 30, 2016, at 2:39 PM, Thomas Wiens wrote:
> 1) It seems to be impossible to decode a value inside the bitmask as
> signed integer
>
> The "Error code" value should be 16 bit signed integer.
But you said it was a 64-bit unsigned integer:
{ "Error code", "s7comm-plus.returnvalue.errorcod
On Oct 27, 2016, at 8:54 PM, Guy Harris wrote:
> On Oct 27, 2016, at 4:18 PM, Joerg Mayer wrote:
>
>> (the policy 42 stuff fixes
>> the symptom instead of the root cause).
>
> ...the policy 42 stuff. Apple doesn't build libpcap with an @rpath
> insta
On Oct 27, 2016, at 4:18 PM, Joerg Mayer wrote:
> 3) It will neither compile nor link.
>
> The attached patch will make it compile and link
It will also add confusion to the API and ABI on UN*X. Windows is already
weird, so we're stuck with that.
I checked in a change, 65a5b4b53ee23c12b9e823
501 - 600 of 3565 matches
Mail list logo
