On Sep 26, 2011, at 6:47 AM, <[email protected]> wrote: > 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;
That is the correct thing to do. > > 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. None of which it should be doing. > Or is the behaviour a bug in the PN dissector? Yes - it's assuming that it's being handed a tvbuff containing the FCS, *even if the dissector for the link layer knows that there's an FCS*. That's not what link-layer dissectors should be doing; there was a bug, introduced a while ago, where the Ethernet dissector wasn't removing the FCS if it knew it was there, so perhaps that code was written during the period where that bug was present. I will remove that code from the PN dissector and leave behind a comment explaining why there is no FCS handling code there. ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
