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