Way how frames are read in pppd

Way how frames are read in pppd

[Christian]

Hi List (James:-)

I have still some issues with my litle project. Let me explain for short
what i'm doing:


Application (synchdlc) <---> Stdin/Stdout <----> pppd (synchdlc)


to ensure boundaries i have hacked pppd to add framing for stdin/stdout,
so that packets in pppd transmitted to stdout contain headers and
packets received contain headers as well.


My problem is the following:

I don't understand where exactly the  PPP(IP) frames are read in pppd
and transmitted to the master_pty. It is certainly not (only) in
read_packet. I have found out that the kernel writes correct packets
with copy_to_user to the userspace. pppd reads them and somehow
transmits them to the master_fd. At this point the boundaries got lost.

I have tried to read the pppd code for a while, but i think i can't see
the forest anymore because of all the trees.

I would apreciate any help.

cheers,

Christian

Re: Way how frames are read in pppd

[James Carlson]

Christian writes:
> Hi List (James:-)
> 
> I have still some issues with my litle project. Let me explain for short
> what i'm doing:
> 
> 
> Application (synchdlc) <---> Stdin/Stdout <----> pppd (synchdlc)

That diagram doesn't make sense to me.

Standard input and output can be open on a pseudoterminal (pty), and
pppd will work that way, but ptys accept only async data, not sync.

Ptys emulate terminals, which are devices attached to the system by
way of asynchronous ports.  They don't emulate synchronous
interfaces.  You'll need to invent your own sort of pty-like driver if
you want to run synchronous.

> to ensure boundaries i have hacked pppd to add framing for stdin/stdout,
> so that packets in pppd transmitted to stdout contain headers and
> packets received contain headers as well.

That sounds like a brutal hack.  What are you trying to do?

> My problem is the following:
> 
> I don't understand where exactly the  PPP(IP) frames are read in pppd
> and transmitted to the master_pty. It is certainly not (only) in
> read_packet. I have found out that the kernel writes correct packets
> with copy_to_user to the userspace. pppd reads them and somehow
> transmits them to the master_fd. At this point the boundaries got lost.
> 
> I have tried to read the pppd code for a while, but i think i can't see
> the forest anymore because of all the trees.

It's still not at all clear to me what you're trying to do, or why
you're doing it.

You're using async devices here -- ptys -- so why are you expecting
synchronous behavior?

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

Re: Way how frames are read in pppd

[Christian]

Hello James,

>It's still not at all clear to me what you're trying to do, or why
>you're doing it.
>
>You're using async devices here -- ptys -- so why are you expecting
>synchronous behavior?
>
>  
>

OK, maybe i do not understand everything correctly, let me in short
explain what i have:

I have a device which gives me a function to transmit data in a hdlc
frame, so i can just call some function like:

tx_frame(char *p, int l);

and i can be sure the data will come out on the other side in exactly 1
hdlc frame with size l.

on the other hand i have installed a callback like

rx_frame(char *p, int l);

where i receive the data from exactly 1 hdlc frame with length l.

It means i'm handling data directly without any knowledge of hldc,
because the controller supports hdlc coding/decoding.

then i tried to use pppd with stdin/stdout, but this obviously did not
work, because there is no boundaries in stdin/stdout so it will fail
when data packets increase in size or in speed, also i needed to enable
the sync option which made it work for a few small slowly coming packets.

I assume sync=no hdlc, and when not using the sync option pppd will do
hdlc on stdin/stdout, maybe you can enlighten that to me a bit?

I have read that i can set a pty end into N_HDLC mode, so that each read
returns exactly 1 packet, do you think i can handle my task in that way ?


I hope very much you can help me,

Christian

Re: Way how frames are read in pppd

[James Carlson]

Christian writes:
> OK, maybe i do not understand everything correctly, let me in short
> explain what i have:
> 
> I have a device which gives me a function to transmit data in a hdlc
> frame, so i can just call some function like:
> 
> tx_frame(char *p, int l);

OK.  Is that in the kernel or outside of the kernel?

If it's in the kernel, then it sounds like that should be used to
construct a device driver that works as a synchronous serial
interface.  Pppd can then open the driver and work normally -- no pty
needed.  (This -- writing a device driver -- isn't a really PPP
issue.)

If it's in user space, then I believe you'll need to re-encode the
data using AHDLC so that you can pass it over a pty.

> then i tried to use pppd with stdin/stdout, but this obviously did not
> work, because there is no boundaries in stdin/stdout so it will fail
> when data packets increase in size or in speed, also i needed to enable
> the sync option which made it work for a few small slowly coming packets.
> 
> I assume sync=no hdlc,

"Sync" means that the device driver is assumed to perform basic
HDLC-like framing.  This means that when pppd writes a single frame,
it'll be transmitted raw (no prepended octets, such as HDLC address or
control, as pppd itself supplies these), with bit-stuffing and FCS
generation being the responsibility of the driver.

That is not true of ptys.

Note that the problem is *NOT* just with pppd itself.  Pppd does not
actually handle the data packets.  Even if you can "trick" pppd into
using some non-sync device as though it were sync, you still need to
deal with the fact that data packets (IP, for instance) are handled in
the kernel.

> and when not using the sync option pppd will do
> hdlc on stdin/stdout, maybe you can enlighten that to me a bit?

When "sync" isn't used, pppd assumes that the driver is asynchronous,
and it uses AHDLC (RFC 1662) coding on the line.

> I have read that i can set a pty end into N_HDLC mode, so that each read
> returns exactly 1 packet, do you think i can handle my task in that way ?

Maybe.  I've never seen that done, and I don't know of any system
where that works.  If it works on Linux, then I guess you may have
found a solution.

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

Re: Way how frames are read in pppd

[Christian]

>OK.  Is that in the kernel or outside of the kernel?
>
>  
>
it's in userspace.

>If it's in user space, then I believe you'll need to re-encode the
>data using AHDLC so that you can pass it over a pty.
>
>  
>
do you know of any library implementing AHDLC ? I'm right now trying to
use spandsps implemetation, but it seems not receive a frame..

Re: Way how frames are read in pppd

[James Carlson]

Christian writes:
> >If it's in user space, then I believe you'll need to re-encode the
> >data using AHDLC so that you can pass it over a pty.
> >
> >  
> >
> do you know of any library implementing AHDLC ? I'm right now trying to
> use spandsps implemetation, but it seems not receive a frame..

You can feel free to use this one:

  ftp://ftp.workingcode.com/pub/carlson/ppp/ahdlc.c
  ftp://ftp.workingcode.com/pub/carlson/ppp/ahdlc.h

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

Re: Way how frames are read in pppd

[Christian]

>>>      
>>>
>>do you know of any library implementing AHDLC ? I'm right now trying to
>>use spandsps implemetation, but it seems not receive a frame..
>>    
>>
>
>  
>
I've done some progress in using the hdlc stuffing/destuffing from
spandsp, it reports that it first has some good FRAME_OK, then after 3
bytes it gets an ABORT, but still says it found a (bad) frame, which
looks like:

received [37]: 3f f1 0 a1 9f d0 4f e8 27 f0 b3 f8 89 fc 64 7e 2 3f 81 9f
c0 4f e0 27 f5 93 cd fb c9 e3 8d fc e4 7e 22 3f 85

would you say this is a correct ppp frame? (looks like it contains a 7e
which should be part of hdlc i think .. )

>You can feel free to use this one:
>
>  ftp://ftp.workingcode.com/pub/carlson/ppp/ahdlc.c
>  ftp://ftp.workingcode.com/pub/carlson/ppp/ahdlc.h
>
>  
>
I tried to fetch them, but i got:


wget ftp://ftp.workingcode.com/pub/carlson/ppp/ahdlc.c
--15:58:57--  ftp://ftp.workingcode.com/pub/carlson/ppp/ahdlc.c
           => `ahdlc.c'
Resolving ftp.workingcode.com... 24.128.38.122
Connecting to ftp.workingcode.com[24.128.38.122]:21... connected.
Logging in as anonymous ... ^[[ALogged in!
=> SYST ... done.    => PWD ... done.
=> TYPE I ... done.  => CWD /pub/carlson/ppp ... done.
=> PASV ...


couldn't connect to 24.128.38.122:31221: Connection timed out
Retrying.




Many thanks so far for clarifying these things to me :-)

Re: Way how frames are read in pppd

[James Carlson]

Christian writes:
> I've done some progress in using the hdlc stuffing/destuffing from
> spandsp, it reports that it first has some good FRAME_OK, then after 3
> bytes it gets an ABORT, but still says it found a (bad) frame, which
> looks like:
> 
> received [37]: 3f f1 0 a1 9f d0 4f e8 27 f0 b3 f8 89 fc 64 7e 2 3f 81 9f
> c0 4f e0 27 f5 93 cd fb c9 e3 8d fc e4 7e 22 3f 85
> 
> would you say this is a correct ppp frame? (looks like it contains a 7e
> which should be part of hdlc i think .. )

You didn't mention whether this is *before* AHDLC encoding or *after*
or whether it represents a complete sequence of some sort or a
fragment from a data stream, but, in any event, it doesn't look like
anything at all to me.

That initial 3f f1 sequence doesn't look like any kind of PPP frame.

> >You can feel free to use this one:
> >
> >  ftp://ftp.workingcode.com/pub/carlson/ppp/ahdlc.c
> >  ftp://ftp.workingcode.com/pub/carlson/ppp/ahdlc.h
> >
> >  
> >
> I tried to fetch them, but i got:

I'll send you a copy by email.

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

Re: Way how frames are read in pppd

[Paul Mackerras]

Christian writes:

> I have a device which gives me a function to transmit data in a hdlc
> frame, so i can just call some function like:
> 
> tx_frame(char *p, int l);
> 
> and i can be sure the data will come out on the other side in exactly 1
> hdlc frame with size l.
> 
> on the other hand i have installed a callback like
> 
> rx_frame(char *p, int l);
> 
> where i receive the data from exactly 1 hdlc frame with length l.

Have a look at Documentation/networking/ppp_generic.txt and
drivers/net/ppp_synctty.c in the Linux kernel sources.

Paul.

Re: Way how frames are read in pppd

[Christian]

Hi James,

>>>You can feel free to use this one:
>>>
>>> ftp://ftp.workingcode.com/pub/carlson/ppp/ahdlc.c
>>> ftp://ftp.workingcode.com/pub/carlson/ppp/ahdlc.h
>>>
>>> 
>>>
>>>      
>>>
>>I tried to fetch them, but i got:
>>    
>>
>
>I'll send you a copy by email.
>  
>

I could easily integrate your hdlc implementation, and it works like a
charm! I even do not need to crudely patch pppd, that's really good !

Thank you very much James !

You can see your hdlc implementation in our application bundle at
www.beronet.com/downloads/apps/app_bundle.tar.gz
 in the next few days.

I will mention your work in the README.

Christian