On Wed, Apr 27, 2005 at 04:41:52PM -0700, Crist J. Clark wrote: > > However, I'm seeing some weirdness, and I wonder if any PPP > gurus can comment. My end sends a ping (a HDLC dump), > > ff 03 c0 21 09 01 00 10 6d a8 39 0d 59 4e 4f 54 00 00 00 01 52 b6 > ^^^^^ ^^^^^ ^^ ^^ ^^^^^ ^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^ > PPP LCP Id Len. Magic No. Data FCS > Echo- > Request > > And receives this, > > ff 03 c0 21 0a 01 00 14 e8 67 ea ac 6d a8 39 0d 59 4e 4f 54 00 00 00 01 29 > 35 > ^^^^^ ^^^^^ ^^ ^^ ^^^^^ ^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > ^^^^^ > PPP LCP Id Len. Magic No. Data FCS > Echo- > Reply > > Which looks a bit strange to me. My end is rejecting those echoes > as bogus because the data we send does not match the data we get back. > What looks like is happening is that the other end of the PPP > is taking the Magic Number field from the echo request and copying > it into the data field. That also explains why the response is 4 bytes > longer than the request. > > I'm no PPP expert, but this is looking pretty fishy. Is the other > end totally broken? However, RFC1661 isn't totally explicit about > how the data field needs to be handled, > > Data > > The Data field is zero or more octets, and contains uninterpreted > data for use by the sender. The data may consist of any binary > value. The end of the field is indicated by the Length. > > But it seems wrong to modify the data field.
It is wrong. Is the other end OS/2 or something derived from it? I recall, from a decade ago, that this was about what some version of OS/2 did wrong. -- Barney Wolff http://www.databus.com/bwresume.pdf I never met a computer I didn't like. _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
