Hi,
I’m currently implementing
a new pcap link-layer type which contains an Ethernet frame including the FCS
(see LINKTYPE_NETANALYZER on http://www.tcpdump.org/linktypes.html).
Now I have observed a problem
with the PROFINET dissector, I’m not sure how to deal with it, and
I’m not sure if even other dissectors are affected.
From the pcap file I read:
+----------------------+
+ Link_layer
header +
+----------------------+
+
+
+ Ethernet frame data +
+
+
+- - - - - - - - - - - +
+ Ethernet
FCS +
+----------------------+
The WTAP dissector dissects the
link-layer header and generates a new tvb subset containing only the Ethernet
frame data + FCS (cuts of the link-layer header). This tvb subset is passed to
the “eth_withfcs” dissector.
In pcap_read_post_process() I
added the new encap type and set the pseudo-headers FCS length to 4:
case WTAP_ENCAP_NETANALYZER:
pseudo_header->eth.fcs_len = 4;
break;
Now I open a pcap file containing
a PN-PTCP DelayRes frame, which results in a malformed packet expert info
“exception occurred”. Looking at the packet-pn-rt.c source code in
dissect_pn_rt() there are some manipulations regarding
pinfo->pseudo_header->eth.fcs_len and tbv reported length.
If I change my assignment in
pcap_read_post_process() to
pseudo_header->eth.fcs_len =
-1;
the frame can be dissected
correctly without error.
Now my question:
I thought I have to set
pseudo_header->eth.fcs_len to 4, as the tvb contains the FCS, but this does
result in false dissection of packets. Am I wrong and do I have to set
pseudo_header->eth.fcs_len to -1? Will this work witch all other dissectors?
Or is the behaviour a bug in the PN dissector?
Regards,
Holger
