Wireshark-bugs: [Wireshark-bugs] [Bug 11139] Return TCP packets aren't labeled with protocol des
Comment # 1
on bug 11139
from Guy Harris
(In reply to yuri from comment #0)
> When client connects to NFS on TCP port 2049, only packets going out to the
> server are labeled "NFS", and returning ones are labeled "TCP".
Not in the capture I just opened up.
> Wireshark can easily follow the TCP stream, therefore it can determine
> that return packets are also NFS.
And, in fact, for *ANY* ONC RPC protocol, that's exactly what it does; see the
conversation_set_dissector() calls in epan/dissectors/packet-rpc.c. Once the
ONC RPC dissector sees the packet, it can hand it off to the appropriate
subdissector (NFS, NIS, whatever) based on the program number in a call or
based on the program number for the corresponding call for a reply.
If you have a capture where server -> client TCP segments *that actually
contain data* - i.e., *NOT* ACK-only packets - aren't marked as NFS, please
attach it to this bug.
If, however, you're referring to ACK-only packets, that's a different matter;
that would be an *enhancement*, requesting that TCP segments without data be
marked as being for one of the protocols being used in the connection.
Note that a given TCP connection can carry more than one higher-level protocol,
e.g. with a plain-text protocol switching to a TLS-based version, or HTTP
CONNECT tunneling, or a port 2049 connection that includes both NFS and "NFS
ACL" protocol calls and responses.
Note also that a single ACK can acknowledge data for more than one higher-level
protocol.
> * So my first suggestion is to label the return packets with the same
> protocol, at least for TCP
>
> * My second suggestion is to label them hierarchically: not just "NFS" but
> "TCP/NFS", (or UDP/NFS, UDP/DHCP). Explicit names are always good, makes it
> more clear. If you think there will be objections, make this the user option.
That's a separate request, and it's not clear that's the right way to handle
that issue. Perhaps, instead, it should be possible to open up the row for a
given frame so that you can see the appropriate Protocol, Info, and other
columns for each protocol layer.
> * The third suggestion is to also label SYN/ACK/FIN packets with protocol.
> Currently SYN/ACK/FIN packets related to some known protocol are only
> labeled as "TCP". It would make sense to label them the same way as data
> packets.
That has the same issues as ACK-only packets (which are also not data packets).
You are receiving this mail because:
- You are watching all bug changes.
