On Tue, May 21, 2002 at 01:22:23PM -0400, Mike Richichi wrote:
> 1) I've always had trouble with decoding NCP over IP packets (we're very
> soon going to be a Pure IP shop). It turns out that Ethereal is not
> properly decoding packets with packet signatures enabled.
Is a "packet signature" the 8-byte header with a 4-byte signature value
and a 4-byte length?
Presumably that signature *cannot* be disabled for TCP, unless the NCP
code infers the length of the packet from the contents of the request or
reply, as TCP is a byte-stream protocol, not a packet protocol. (Either
that, or the 4-byte signature can be disabled but the length can't be.)
If it's optional for NCP-over-UDP, then the dissector needs to check
whether the first 4 bytes of the packet are NCPIP_RQST or NCPIP_RPLY
and:
if so, dissect the first 4 bytes as a signature and the next 4
bytes as a length;
if not, dissect the payload as an NCP packet.
> 2) NCP over IP will use burst mode to to large transfers (program and
> data files in bulk) and these are identified as NCP packets but have
> little or no header data, so again the packet type is unknown. This is
> a minor problem though, because it's clear in the trace what's going on
> (there's an NCP open file request, a bunch of large packets with TCP
> ACKs from the server, then an NCP close file request.)
I assume the burst mode for NCP-over-IP is different from the regular
NCP burst mode? The dissector currently dissects the regular NCP burst
mode headers.
> These seem like small issues, and I figured the rewrite of the
> dissector would handle it. I will gladly provide dumps and testing to
> help fix this problem,
I'd like to see examples of
1) NCP-over-IP traffic without the signature;
2) NCP-over-IP traffic with the signature;
3) the burst mode traffic to which you're referring.