After reminding myself about address/control field compression, it
appears to me that the PPP dissector is not expecting (checking for?) a
compressed (ie. NULL) address/control field. Bascially if the address
field is not 0xFF, then the address/control has been compressed.
I'll try to examine the code to see if I can fix it, but since I've not
looked at any of the dissector code before, someone else maybe able to
do it quicker.
Cheers, Greg.
Greg Kilfoyle wrote:
>
> Gilbert Ramirez wrote:
> >
> > On Tue, Apr 04, 2000 at 11:07:27AM -0500, Greg Kilfoyle wrote:
> > >
> > >
> > > Hi,
> > >
> > > I'm attempting to debug a Linux PPTP (MPPE) session and it won't decode
> > > the packets that follow the LCP negotiation.
> > >
> > > The first packet after LCP is an authentication packet (CHAP). The PPP
> > > portion of the packet (after GRE) starts with the PPP protocol (0xc223)
> > > but ethereal is expecting an address and control field.
> > >
> > > LCP negotiation included the 2-bytes address/control field and negotiated
> > > address/control field compression.
> > >
> > > Any ideas?
> >
> > A fix for PPP over GRE was checked into CVS a few days ago. Can you get
> > the current source from CVS and try it? If you can't, I'll make a tar image
> > of the source available.
>
> I updated my CVS tree, and ran ethereal against my capture file. It
> gives the same error for all packets after LCP negotiation. I guess I'm
> going to have to provide some output...I'll use tethereal, and change
> the addresses before submitting.
>
> >
> > --gilbert
>
> --
> Greg Kilfoyle (gregk@xxxxxxxxxxx)
--
Greg Kilfoyle (gregk@xxxxxxxxxxx)
