PPP-layer Echo

[Barney Wolff]

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.