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)
Powered by MHonArc 2.6.10