1. The only indication we get of an out-of-order value string is a message on
STDERR, so check that and fail the test if STDERR wasn't empty.
2. This exposes an out-of-order value string in packet-stun.c; fix it.
3. This triggered the pre-commit hook on packet-stun.c, which noticed an API
error (ENC_ASCII -> ENC_ASCII|ENC_NA); fix that too.
Change-Id: I36f87a2a87b40537119562f22a7e3012716ff239
Lesson: automated testing/tooling is both wonderful and scary.
Reviewed-on: https://code.wireshark.org/review/2682
Reviewed-by: Evan Huus <eapache@gmail.com>
Otherwise glib throws an assertion since the array we pass it is NULL.
Change-Id: I9159c1f5ad99b280c040cd790df3cf352738601f
Reviewed-on: https://code.wireshark.org/review/2680
Reviewed-by: Evan Huus <eapache@gmail.com>
Change-Id: I9339869defa47a862b6174d8821cdd8e6186f5c5
Reviewed-on: https://code.wireshark.org/review/2678
Reviewed-by: Martin Kaiser <wireshark@kaiser.cx>
Tested-by: Martin Kaiser <wireshark@kaiser.cx>
Change-Id: Iac6a259a1081b907149c49023614a5053440e560
Reviewed-on: https://code.wireshark.org/review/2677
Reviewed-by: Martin Kaiser <wireshark@kaiser.cx>
Tested-by: Martin Kaiser <wireshark@kaiser.cx>
Change-Id: I525ac2aae2bdbfd5f3a2f3b35f1bf10dde053f66
Reviewed-on: https://code.wireshark.org/review/2667
Tested-by: Michael Mann <mmann78@netscape.net>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Interactive Connectivity Establishment ICE Extensions 2.0
http://msdn.microsoft.com/en-us/library/office/cc431504.aspx
Change from review:
1) Change encoding for foundation to ASCII
2) Move case for MS_IMPLEMENTATION_VER.
Change-Id: Ic524a2fe811695478aba81af9cbb3dbd031bbce3
Reviewed-on: https://code.wireshark.org/review/2579
Reviewed-by: Evan Huus <eapache@gmail.com>
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Also, make the block of code containing that comment intended
consistently with spaces.
Change-Id: I8e8eb346833662f15c53ece5869b12cc430bad11
Reviewed-on: https://code.wireshark.org/review/2661
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Libpcap 1.6/tcpdump 4.6 will support up to 131072, as the MTU on the
Linux loopback device is 65536 on at least some versions of the kernel,
and that doesn't count the fake Ethernet header, so the maximum packet
size is 65549; they went to the next power of 2 up.
Change-Id: Ibfc66d01ef8ef7387887a75c2b567159bb78ac0f
Reviewed-on: https://code.wireshark.org/review/2655
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Change-Id: I2ea1892b5963cc5578cbdd2b03029ca8424f2267
Reviewed-on: https://code.wireshark.org/review/2640
Tested-by: Michael Mann <mmann78@netscape.net>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Add SIP Flows menu option beside VoIP Calls.
Flow for all SIP message types (which have a call-id) is shown in SIP Flow.
Add useful info(original flow method, response code, cseq) to comment field in conversation and flow dialogs.
Change-Id: I4801a633ed9b6594b2d89629c9d6fec6352da150
Reviewed-on: https://code.wireshark.org/review/2479
Reviewed-by: Evan Huus <eapache@gmail.com>
Reviewed-by: James Coleman <gaoithe@gmail.com>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Down from 500KB. The old value only triggered once that I can recall, and the
"average" leakage I'm seeing on most captures is only a few KB now, so this
shouldn't flood us with issues (which was the original concern leaving it so
high).
Change-Id: Ie4c98696b3fb7a533a7dc4f83c7ac8c458b499c8
Reviewed-on: https://code.wireshark.org/review/2633
Reviewed-by: Michael Mann <mmann78@netscape.net>
Change-Id: I5f573dffabb8685a8e5a334ff2bfb24d9838daa6
Reviewed-on: https://code.wireshark.org/review/2601
Tested-by: Michael Mann <mmann78@netscape.net>
Reviewed-by: Michael Mann <mmann78@netscape.net>
- Respect the length field when dissecting message sets
- Don't "wrap around" in capture when doing request/response matches
Also convert one instance to proto_tree_add_subtree, as an experiment.
Change-Id: Id161687865afa7ca83e6943a643bc54582f65554
Reviewed-on: https://code.wireshark.org/review/2624
Reviewed-by: Evan Huus <eapache@gmail.com>
You can, for example, do
tshark -r file1 -Y filter -w file2
to read a file, apply a read filter, and write the packets that match
the filter to another file even if you can't capture traffic.
Change-Id: Ifd5e1d5c0e745edef5e98ec4babc720bfbcee6d9
Reviewed-on: https://code.wireshark.org/review/2627
Reviewed-by: Guy Harris <guy@alum.mit.edu>
That way, we can include the WinPcap version in that string.
Change-Id: I01fa0defce158e122d1c602fdfbc81916a9e80ef
Reviewed-on: https://code.wireshark.org/review/2625
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Bug: 9460
Change-Id: I80d991053eb47b8650561e8af4cc8dec512e2c9c
Reviewed-on: https://code.wireshark.org/review/2619
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Bug: 7870
Change-Id: I6cea057c4953f5ecc0a146a24570d089e79f8352
Reviewed-on: https://code.wireshark.org/review/2620
Reviewed-by: Michael Mann <mmann78@netscape.net>
The indented portions are inside an if.
Change-Id: I3343a7aa7e777466ec9f40e8a02a8218bef62017
Reviewed-on: https://code.wireshark.org/review/2622
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Reviewed-by: Michael Mann <mmann78@netscape.net>
I have ***NO*** idea why this makes a difference, but, without this
change, APPLE_CORE_FOUNDATION_LIBRARY is apparently *not* set correctly
for wsutil/CMakeLists.txt, and, with this change, it is. I guess
there's something magic involved here with "global" CMake variables or
something crazy such as that.
Change-Id: I7a0046b9c249568cd666720838104f48e854e203
Reviewed-on: https://code.wireshark.org/review/2612
Reviewed-by: Guy Harris <guy@alum.mit.edu>
see mon_bin_event() in the linux kernel where the setup_flag is set only
for control urbs
clean up various things related to this assertion:
remove type_2 parameter
show the iso descriptors in any case
calculate the end offset correctly, the end offset is the byte after the
iso data
Change-Id: Iebfbe6443c224a958a1697563aa8fb853d7aa8c2
Reviewed-on: https://code.wireshark.org/review/2541
Reviewed-by: Martin Kaiser <wireshark@kaiser.cx>
Tested-by: Martin Kaiser <wireshark@kaiser.cx>