On Sep 26, 2011, at 6:47 AM, <HPfrommer@xxxxxxxxxxxx> 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.
