Subject: tty-device when using capiplugin - msg#00033

Previous Message by Date:

Re: syncppp

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 - To unsubscribe from this list: send the line "unsubscribe linux-ppp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html

Next Message by Date:

failure during first LCP Packets

I am connecting to a Endres and Hauser Fieldgate modem using pppd 2.4.1 and capiplugin 1.31 or an analog modem from behind a telephone system. Sometimes it works flawlessly, but sometimes the remote modem seems not to hear the pppd's answer. It sends the CHAP or IPCP packet several times, and pppd answers it every time, but it does not lead to success. It is the same behaviour with several remote modems of the same type and from different linux systems. There are indices that this behaviour does not occur, when calling the remote modem from outside the company, but I didn't verify that so long. Does anybody know what may be going on here, and has a hint how to work around? Thilo - To unsubscribe from this list: send the line "unsubscribe linux-ppp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html

Previous Message by Thread:

syncppp

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 - To unsubscribe from this list: send the line "unsubscribe linux-ppp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html

Next Message by Thread:

failure during first LCP Packets

I am connecting to a Endres and Hauser Fieldgate modem using pppd 2.4.1 and capiplugin 1.31 or an analog modem from behind a telephone system. Sometimes it works flawlessly, but sometimes the remote modem seems not to hear the pppd's answer. It sends the CHAP or IPCP packet several times, and pppd answers it every time, but it does not lead to success. It is the same behaviour with several remote modems of the same type and from different linux systems. There are indices that this behaviour does not occur, when calling the remote modem from outside the company, but I didn't verify that so long. Does anybody know what may be going on here, and has a hint how to work around? Thilo - To unsubscribe from this list: send the line "unsubscribe linux-ppp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html