[Wireshark-bugs] [Bug 11920] IO Graph: NFS/RPC not congruent with underlaying TCP

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11920

Jim Young  changed:

   What|Removed |Added

 Status|INCOMPLETE  |RESOLVED
 CC||jyo...@gsu.edu
 Resolution|--- |NOTABUG

--- Comment #10 from Jim Young  ---
Hello Carsten,

The reason that the "NFS" and "RPC" bytes/sec graphs are so much lower than the
"Stream 0" graph is because your trace contains many fewer NFS and RPC frames
than it does TCP frames!

In your sample trace (thanks) 100% of the packets match the display filter of
"tcp.stream==0" but only 6.9% of the frames match a display filter of "rpc" or
of "nfs".

>From your screen shots you've configured the IO Graph to plot three different
graphs.

#1 - a count of the bytes (per second) for "tcp.stream==0" frames
#2 - a count of the bytes (per second) for "nfs" frames
#3 - a count of the bytes (per second) for "rpc" frames

These IO graphs simply plot the sum of the frame lengths of the packets that
match each of the filters for the configured time interval (in this case one
second).

Obviously what you want really want to plot is the lengths of RPC and NFS
packets.

As you are aware NFS is encapsulated in RPC and in this case RPC is
encapsulated in TCP.  But each RPC packet is sent in multiple TCP segments. 
The complete set of TCP segments must be reassembled to create the original
RPC/NFS packet.  Wireshark only displays the reassembled RPC/NFS packet in the
last packet of each reassembled TCP segment train.  So only the last TCP packet
of each TCP segment train ends up matching the display filters of "nfs" or
"rpc".

I believe you can achieve your objective by plotting the
"tcp.reassembled.length",
"rpc.fraglen" and/or perhaps the "nfs.count3" field values. 

To generate a graph of the RPC bytes per second configure the "Display Filter"
field with the value "rpc", the "Y Axis" field with the formula "Sum(Y Field)"
and the "Y Field" with the field value "tcp.reassembled.length".  This will
plot the length of the complete RPC packet including the RPC header.

To generate a graph of the NFS bytes per second configure the "Display Filter"
field with the value "nfs", the "Y Axis" field with the formula "Sum(Y Field)"
and the "Y Field" with the field value "rpc.fraglen".  I'm no RPC/NFS expert
but this appears to plot the length of the complete NFS packet including the
NFS header.

It becomes a little harder to generate a graph of just the NFS payload bytes
per second.   If you configure a "Display Filter" field value of "nfs" and
the"Y Axis" field with the formula "Sum(Y Field)" and the "Y Field" with the
field value "nfs.count3" you will see a plot twice as high as expected.  This
is because the field "nfs.count3" exists both in the NFS WRITE Call packets and
the and NFS Write Reply packets.  To generate a graph more in line with the
actual bytes transmitted you could simply augment the "Display Filter" field
with something like "nfs && ip.src==", where  is the host
that is transmitting the file.

To help illustrate the differences in these three field's values you might want
to add Custom Columns to Wireshark's Packet List for "tcp.reassembled.length",
"rpc.fraglen" and "nfs.count3".  This will allow you to compare the three
values side by side and determine which value(s) might be best for your needs. 
Displaying them in the Custom Column in this manner will also help with
understanding why simply plotting the "nfs.count3" could result in a plot twice
as high as expected. 

With the modified IO Graph Y Axis and Y Field value in place I believe you will
see the IO Graph congruency you expect.

If you believe this analysis is incorrect please feel free to reopen this bug.

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 11952] Create API to more easily have fields copied to higher tree

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11952

--- Comment #5 from Michael Mann  ---
(stupid tab button.  Continuing...)

enum field_data {
PI_FIELD_COMPLETE, //Show field name and value
PI_FIELD_VALUE, //Show just field value
PI_FIELD_VS_ONLY //Show just field value_string
(and I'm sure we could come up with a few other categories)

What I want to be able to do with proto_item_append_field is "lazy processing"
and only populate the field/text value when it needs to be there, just like
proto_tree_add_item (and friends).  I think the internals are there to do it, I
just haven't figured out how. 
proto_item_append_text has to do more processing when it's called and can't
offload until later.  That's what I want the big benefit of
proto_item_append_field to be.

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 11952] Create API to more easily have fields copied to higher tree

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11952

--- Comment #4 from Michael Mann  ---
This enhancement probably started with an eye towards TLVs, but I also had the
"wanting to copy value to parent tree" case in mind.
I think a proto_tree_add_tlv could be a possibility, but I was also thinking
about something like proto_item_append_field.

Rough signature:
enum field_data {
PI_FIELD_COMPLETE, PI_FIELD_VALUE, PI_FIELD_VS_ONLY};

void proto_item_append_field(proto_item* parent_item, proto_item* field_item,
enum field_data);

Pseudocode:
parent = proto_tree_add_item(tree, hf, tvb, offset, 2, ENC_BIG_ENDIAN);
item = proto_tree_add_item(tree, hf_other, tvb, offset, 2, ENC_BIG_ENDIAN);
/* Add value to parent */
proto_item_append_field(parent, item, PI_FIELD_VALUE

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13193] Support for DTLS-SRTP (used by WebRTC) with SIP signalling over Websockets

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13193

--- Comment #4 from Peter Wu  ---
The SDP dissector could use some refactoring to make extensions easier
(https://code.wireshark.org/review/19047). References for further refinement:

SDP: Session Description Protocol
https://tools.ietf.org/html/rfc4566

An Offer/Answer Model with the Session Description Protocol (SDP)
https://tools.ietf.org/html/rfc3264

Session Initiation Protocol (SIP) Usage of the Offer/Answer Model
https://tools.ietf.org/html/rfc6337

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12230] Export HTTP Objects - Single file shows as multiple files in 2.0.2

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12230

Peter Wu  changed:

   What|Removed |Added

 CC||pe...@lekensteyn.nl

--- Comment #9 from Peter Wu  ---
I can still reproduce the issue with 2.0.1, but the patch above fixes the
problem for me (also tested a backport with 2.2, that needs a conflict
resolition but otherwise fixes the problem too).

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12230] Export HTTP Objects - Single file shows as multiple files in 2.0.2

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12230

--- Comment #8 from Gerrit Code Review  ---
Change 19055 had a related patch set uploaded by Peter Wu:
Qt: clear Export Objects list on retapping

https://code.wireshark.org/review/19055

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13044] Buildbot crash output: fuzz-2016-10-25-19751.pcap

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13044

Peter Wu  changed:

   What|Removed |Added

 CC||pe...@lekensteyn.nl

--- Comment #16 from Peter Wu  ---
I'm unable to reproduce the uninitialized variable warning under valgrind 3.12,
gcc 6.2.1 on Arch Linux x86_64. ASAN does also not complain. Manual inspection
suggests that everything should work.

On Ubuntu 16.04 I can also not reproduce it with CMake (both
-DCMAKE_BUILD_TYPE=Debug and -DCMAKE_BUILD_TYPE=DebWithRelInfo) nor autotools
(./configure without options) with commit
ce9405b00b0bc49fef5a21f984251a1e0065580b. The only complaint I get is:

==29022== Memcheck, a memory error detector
==29022== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==29022== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==29022== Command: run/tshark -nr /tmp/fuzz-2016-10-25-19751.pcap
==29022== 
==29022== Conditional jump or move depends on uninitialised value(s)
==29022==at 0xA9B59D6: ws_mempbrk_sse42_compile (ws_mempbrk_sse42.c:69)
==29022==by 0x726EC02: register_all_protocols (register.c:2725)
==29022==by 0x73463F7: proto_init (proto.c:534)
==29022==by 0x7322746: epan_init (epan.c:132)
==29022==by 0x115E64: main (tshark.c:805)
==29022== 


Is anyone else able to reproduce this valgrind report?

The only reason why this could possibly fail is when the compiler did an
optimization which was not understood by valgrind. opcode is a guint8,
solicited a gboolean (just an int), maybe the compiler "optimized" this by
loading a 64-bit number...

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13142] tshark -z follow not showing both hosts

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13142

Michael Mann  changed:

   What|Removed |Added

 Status|UNCONFIRMED |INCOMPLETE
 Ever confirmed|0   |1
   Severity|Major   |Normal

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13200] Buildbot crash output: fuzz-2016-12-02-8532.pcap

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13200

Michael Mann  changed:

   What|Removed |Added

 Status|CONFIRMED   |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Michael Mann  ---


*** This bug has been marked as a duplicate of bug 13044 ***

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13044] Buildbot crash output: fuzz-2016-10-25-19751.pcap

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13044

--- Comment #15 from Michael Mann  ---
*** Bug 13200 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 11363] IB: Create single conversation for Infiniband connections whenever possible

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11363

--- Comment #2 from Gerrit Code Review  ---
Change 18982 merged by Michael Mann:
packet-infiniband: Fixed duplicate conversation entries

https://code.wireshark.org/review/18982

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 11363] IB: Create single conversation for Infiniband connections whenever possible

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11363

Gerrit Code Review  changed:

   What|Removed |Added

 Status|CONFIRMED   |RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe