syncppp

syncppp

[Christian]

Hi List,

i'm trying to understand how ppp transports frames in the "sync" mode. I
want to do the following scenario:

pppd sync notty

I've hacked pppd  to use a simple framing method for stdin/stdout, to
guarantee the transport of complete ppp frames. But unfortunately i
found out, that in the tty.c i get mixed up frames from the
master_pty_f, like i read a buffer and in the buffer i get :

[ppp frame 1][part of ppp frame 2]

the next buffer contains then:

[rest of ppp frame 2]


so that is what i transmit to my sync device, but the other side rejects
the second frame because it seems not valid.

I don't really understand yet where pppd reads the frames from the
kernel device, maybe somebody could give me a pointer.

I just want to check if the frames come like that from the kernel or if
it happens because the slave side pty-buffer gets full befor we can read
it on the master side, so the framing is messed up.


Thanks for any help!

Christian

Re: syncppp

[James Carlson]

Christian writes:
> i'm trying to understand how ppp transports frames in the "sync" mode. I
> want to do the following scenario:

In sync mode, each write from pppd represents a complete PPP frame,
including the HDLC-like Address and Control fields, but not including
the trailing FCS or any 0-bit stuffing.

Each read returns a complete PPP frame, again including the HDLC-like
Address and Control fields, but not including the FCS or 0-bit
stuffing.

> I've hacked pppd  to use a simple framing method for stdin/stdout, to
> guarantee the transport of complete ppp frames.

I'm confused.  At what point are stdin/stdout connected to a sync
device that preserves frame boundaries?

> But unfortunately i
> found out, that in the tty.c i get mixed up frames from the
> master_pty_f, like i read a buffer and in the buffer i get :

If you're talking about ptys, then you're not talking about sync.

> so that is what i transmit to my sync device, but the other side rejects
> the second frame because it seems not valid.

Indeed.  It looks like you have an async stream (a pty pair) in the
way.

> I don't really understand yet where pppd reads the frames from the
> kernel device, maybe somebody could give me a pointer.

It happens in the read_packet() function.

> I just want to check if the frames come like that from the kernel or if
> it happens because the slave side pty-buffer gets full befor we can read
> it on the master side, so the framing is messed up.

I think using a pty pair and expecting sync-like operation to happen
is just a bug.  It won't work, because ptys are async serial emulation
devices.

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>

Re: syncppp

[Christian]

Hi James,


James Carlson wrote:

>Christian writes:
>  
>
>>i'm trying to understand how ppp transports frames in the "sync" mode. I
>>want to do the following scenario:
>>    
>>
>
>In sync mode, each write from pppd represents a complete PPP frame,
>including the HDLC-like Address and Control fields, but not including
>the trailing FCS or any 0-bit stuffing.
>
>  
>

This is not totally true. I found out that the ppp_synch module makes
copy_to_users of 1502 bytes (default mtu), interestingly pppd reads 1504
bytes (MRU+PPP_HDR), which leads to problems in synch mode because 2
bytes of the next frame are inside of the current frame, i don't know
why this does not create issues in other constelllations, but in mine it
does. So i just changed the maximum read to MRU+PPP_HDR-2 in the tty.c
file and indeed it worked for me immediately.

>Each read returns a complete PPP frame, again including the HDLC-like
>Address and Control fields, but not including the FCS or 0-bit
>stuffing.
>
>  
>
>>I've hacked pppd  to use a simple framing method for stdin/stdout, to
>>guarantee the transport of complete ppp frames.
>>    
>>
>
>I'm confused.  At what point are stdin/stdout connected to a sync
>device that preserves frame boundaries?
>
>  
>
I have hacked the tty.c to prepend each write with a length field, so i
added boundaries, my programm connects to stdin/stdout and reads the
length field and therefore knows what a frame means.

>>But unfortunately i
>>found out, that in the tty.c i get mixed up frames from the
>>master_pty_f, like i read a buffer and in the buffer i get :
>>    
>>
>
>If you're talking about ptys, then you're not talking about sync.
>
>  
>

well the notty option leads to a Master/Slave pty which is connected to
the stdin/stdout pipes in the charshunt() as far as i understood.

It seems to me pppd needs terminal like fds internally, but i don't
really understand why this is so.


But anyway my fix solved my problems now.

Thanks for your time!

Cheers,

Christian

Syncppp

[Matt Schulkind]

In the 2.2.16 kernel, it seems that the ppp_device structure was changed to
use a pointer to the net device instead of haveing the structure contained
within, and the if_down procedure was changed accordingly to use the sppp_of
macro. But, if I take a look at the 2.4.x kernel sources, it seems only the
first change, the pointer vs. struct change was made, but the if_down
procedure was not changed. I believe this is a bug and the if_down procedure
in the 2.4.x kernel must be changed to match 2.2.16+. Could anyone confirm
this?

Please CC me personally with any replies.

-Matt Schulkind

Re: Syncppp

[Paul Fulghum]

> In the 2.2.16 kernel, it seems that the ppp_device structure was changed to
> use a pointer to the net device instead of haveing the structure contained
> within, and the if_down procedure was changed accordingly to use the sppp_of
> macro. But, if I take a look at the 2.4.x kernel sources, it seems only the
> first change, the pointer vs. struct change was made, but the if_down
> procedure was not changed. I believe this is a bug and the if_down procedure
> in the 2.4.x kernel must be changed to match 2.2.16+. Could anyone confirm
> this?
> -Matt Schulkind

It looks like you are right. The current 2.4 code
appears to scribble into the net_device structure
someplace (yuck) when if_down() is called.

I'm going to change this and test it tomorrow to be
for sure.

Paul Fulghum paulkf@microgate.com
Microgate Corporation www.microgate.com

Re: Syncppp

[Bob Dunlop]

Hi,

On Mon, Aug  6,  Paul Fulghum wrote:
> > In the 2.2.16 kernel, it seems that the ppp_device structure was changed to
> > use a pointer to the net device instead of haveing the structure contained
> > within, and the if_down procedure was changed accordingly to use the sppp_of
> > macro. But, if I take a look at the 2.4.x kernel sources, it seems only the
> > first change, the pointer vs. struct change was made, but the if_down
> > procedure was not changed. I believe this is a bug and the if_down procedure
> > in the 2.4.x kernel must be changed to match 2.2.16+. Could anyone confirm
> > this?
> > -Matt Schulkind
> 
> It looks like you are right. The current 2.4 code
> appears to scribble into the net_device structure
> someplace (yuck) when if_down() is called.

I agree it's a bug.
Well spotted!  How many times have I scrolled past that line?

On Intel (i386) it looks like it clobbers last_rx which is probably harmless,
but it's close to some hairy pointers so who knows on other architectures.
The fact that pp_link_state is not being reset could well explain how I was
getting into that negotiation loop problem earlier in the year.  The loop
fix is still a valid safety however.

> I'm going to change this and test it tomorrow to be
> for sure.

Well I've applied the obvious fix (below) and tested it on Intel with the
Farsync driver and all looks good.  Don't have access to other architectures
for any other testing.


--- linux/drivers/net/wan/syncppp.c.orig	Thu Jun 28 01:10:55 2001
+++ linux/drivers/net/wan/syncppp.c	Tue Aug  7 08:14:43 2001
@@ -156,7 +156,7 @@
 
 static void if_down(struct net_device *dev)
 {
-	struct sppp *sp = &((struct ppp_device *)dev)->sppp;
+	struct sppp *sp = (struct sppp *)sppp_of(dev);
 
 	sp->pp_link_state=SPPP_LINK_DOWN;
 }



-- 
        Bob Dunlop
        FarSite Communications Ltd.
        http://www.farsite.co.uk/

Re: Syncppp

[Paul Fulghum]

> On Intel (i386) it looks like it clobbers last_rx which is probably harmless,
> but it's close to some hairy pointers so who knows on other architectures.
> The fact that pp_link_state is not being reset could well explain how I was
> getting into that negotiation loop problem earlier in the year.  The loop
> fix is still a valid safety however.

Part of the problem is the masochistic construction of
the (ppp_device/net_device/struct sppp/serial context data)
quad. A nasty mess of casts and followed pointers
likely to make your head spin (and your code wrong).

Paul Fulghum paulkf@microgate.com
Microgate Corporation www.microgate.com