ppp_generic escape character problem. - PPP

This is a discussion on ppp_generic escape character problem. - PPP ; Hi all, Let's say that I'm use an FPGA (that includes HDLC controleur) to make PPP over ISDN, I use a kernel module tp plug into the ppp_generic layer (Kernel 2.4.20) Once ppp connection established, I can download both binary ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: ppp_generic escape character problem.

  1. ppp_generic escape character problem.

    Hi all,

    Let's say that I'm use an FPGA (that includes HDLC controleur) to make
    PPP over ISDN,
    I use a kernel module tp plug into the ppp_generic layer (Kernel
    2.4.20)

    Once ppp connection established, I can download both binary and ASCII
    files, but when uploading binary file are cut.

    I know that some where in the kernel, bytes from 0x00 to 0x31 are
    interpreted as a control character. I't shouldn't in my case

    in async mode a map is used to indicate to peers witch character to
    escape or not, but I don't need that ?

    Does somne one know how to tell the kernel to not interprete special
    characters and just let them pass ?

    thank you so much

    Younes.

    #################### LOG ###########################
    target:~# pppd /dev/ppp_isdn -detach sync ktune local silent debug
    kdebug 7 nopcomp nocrtscts 192.1.1.1:192.1.1.25
    using channel 2
    Using interface ppp0
    Connect: ppp0 <--> /dev/ppp_isdn
    rcvd [proto=0x586c] 4c 6c 58 26 ff 03 c0 21 01 00 00 11 05 06 7e f4 15
    d7 07 02 08 02 0d 03 06
    Discarded non-LCP packet when LCP not open
    rcvd [LCP ConfReq id=0x1 CBCP>]
    sent [LCP ConfReq id=0x1 ]
    sent [LCP ConfRej id=0x1 ]
    rcvd [LCP ConfAck id=0x1 ]
    rcvd [LCP ConfReq id=0x2 ]
    sent [LCP ConfAck id=0x2 ]
    sent [LCP EchoReq id=0x0 magic=0x15f89038]
    kernel does not support PPP filtering
    sent [IPCP ConfReq id=0x1 ]
    rcvd [LCP Ident id=0x3 magic=0x7ef415d7 "MSRASV5.10"]
    rcvd [LCP Ident id=0x4 magic=0x7ef415d7 "MSRAS-0-PAPEETE"]
    rcvd [LCP EchoRep id=0x0 magic=0x7ef415d7]
    rcvd [IPCP ConfReq id=0x5 0.0.0.0> ]
    sent [IPCP ConfRej id=0x5 0.0.0.0> ]
    rcvd [IPCP ConfAck id=0x1 ]
    rcvd [IPCP ConfReq id=0x6 ]
    sent [IPCP ConfNak id=0x6 ]
    rcvd [IPCP ConfReq id=0x7 ]
    sent [IPCP ConfAck id=0x7 ]
    local IP address 192.1.1.1
    remote IP address 192.1.1.25
    Script /etc/ppp/ip-up started (pid 765)
    Script /etc/ppp/ip-up finished (pid 765), status = 0x0

    #################### END LOG ###########################


  2. Re: ppp_generic escape character problem.

    behloul.maliste@gmail.com writes:
    > I know that some where in the kernel, bytes from 0x00 to 0x31 are
    > interpreted as a control character. I't shouldn't in my case


    Right. You should be using sync mode (as I see from at least the PPP
    options you are).

    > in async mode a map is used to indicate to peers witch character to
    > escape or not, but I don't need that ?


    Correct.

    > Does somne one know how to tell the kernel to not interprete special
    > characters and just let them pass ?


    You should not have to do such a thing, if the driver is properly
    constructed.

    > target:~# pppd /dev/ppp_isdn -detach sync ktune local silent debug
    > kdebug 7 nopcomp nocrtscts 192.1.1.1:192.1.1.25


    That's an odd list of options.

    "Silent" stops the system from sending PPP packets until the peer
    starts first. Why is that needed?

    "Nocrtscts" shouldn't be needed on a sync interface. Why was that
    added?

    > sent [LCP ConfReq id=0x1 ]


    You might want to include "default-asyncmap" to avoid negotiating this
    parameter. (The parameter ought to do nothing, but perhaps it
    confuses the peer.)

    Everything else in the log appears to indicate that the PPP link
    itself is working properly.

    I suspect that if you're having trouble, the problem isn't in PPP.
    It's likely to be a confused peer or some sort of networking bug.

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

  3. Re: ppp_generic escape character problem.

    behloul.maliste@gmail.com writes:

    >Hi all,


    >Let's say that I'm use an FPGA (that includes HDLC controleur) to make
    >PPP over ISDN,
    >I use a kernel module tp plug into the ppp_generic layer (Kernel
    >2.4.20)


    >Once ppp connection established, I can download both binary and ASCII
    >files, but when uploading binary file are cut.


    >I know that some where in the kernel, bytes from 0x00 to 0x31 are
    >interpreted as a control character. I't shouldn't in my case


    No idea. apparently your system DOES interpret some of the characters as
    control characters. So try setting
    asyncmap 0xfffff
    which would escape them all. or try figuring out which control characters
    ae giving you trouble.

    However you do not do any asyncmap negotiation, so it should be the default
    0xfffff is the asyncmap in both directions. Of course it may be that the
    far side is broken, and is not honouring these.

    Actually looking again they request asyncmap 0 and you request nothing.
    Also probabaly not a good idea. Win MS it is always a good idea to request
    exactly the same asyncmap as they do or they get confused.
    Ie, put
    asyncmap 0x00000 into /etc/ppp/options.






    >in async mode a map is used to indicate to peers witch character to
    >escape or not, but I don't need that ?




    >Does somne one know how to tell the kernel to not interprete special
    >characters and just let them pass ?


    It is not the kernel. It is say the serial driver (eg you decided to use
    xon/xoff flow control to your modem).


    >thank you so much


    >Younes.


    >#################### LOG ###########################
    >target:~# pppd /dev/ppp_isdn -detach sync ktune local silent debug
    >kdebug 7 nopcomp nocrtscts 192.1.1.1:192.1.1.25
    >using channel 2
    >Using interface ppp0
    >Connect: ppp0 <--> /dev/ppp_isdn
    >rcvd [proto=0x586c] 4c 6c 58 26 ff 03 c0 21 01 00 00 11 05 06 7e f4 15
    >d7 07 02 08 02 0d 03 06
    >Discarded non-LCP packet when LCP not open
    >rcvd [LCP ConfReq id=0x1 >CBCP>]
    >sent [LCP ConfReq id=0x1 ]
    >sent [LCP ConfRej id=0x1 ]
    >rcvd [LCP ConfAck id=0x1 ]
    >rcvd [LCP ConfReq id=0x2 ]
    >sent [LCP ConfAck id=0x2 ]
    >sent [LCP EchoReq id=0x0 magic=0x15f89038]
    >kernel does not support PPP filtering
    >sent [IPCP ConfReq id=0x1 ]
    >rcvd [LCP Ident id=0x3 magic=0x7ef415d7 "MSRASV5.10"]
    >rcvd [LCP Ident id=0x4 magic=0x7ef415d7 "MSRAS-0-PAPEETE"]
    >rcvd [LCP EchoRep id=0x0 magic=0x7ef415d7]
    >rcvd [IPCP ConfReq id=0x5 >0.0.0.0> ]
    >sent [IPCP ConfRej id=0x5 >0.0.0.0> ]
    >rcvd [IPCP ConfAck id=0x1 ]
    >rcvd [IPCP ConfReq id=0x6 ]
    >sent [IPCP ConfNak id=0x6 ]
    >rcvd [IPCP ConfReq id=0x7 ]
    >sent [IPCP ConfAck id=0x7 ]
    >local IP address 192.1.1.1
    >remote IP address 192.1.1.25
    >Script /etc/ppp/ip-up started (pid 765)
    >Script /etc/ppp/ip-up finished (pid 765), status = 0x0


    >#################### END LOG ###########################



  4. Re: ppp_generic escape character problem.

    That's kind from you James to help me, thank you.
    James Carlson wrote:

    > > Does somne one know how to tell the kernel to not interprete special
    > > characters and just let them pass ?

    >
    > You should not have to do such a thing, if the driver is properly
    > constructed.


    What does a well constructed driver means for you ?
    I've suspected that also: the pppd ask for many IOCTL, but the
    documentation /Documentation/networking/ppp_generic.txt doesn't explain
    that, so I tried to emulate it like it's done in irnet_ppp.c (PPP over
    Irda)

    > > target:~# pppd /dev/ppp_isdn -detach sync ktune local silent debug
    > > kdebug 7 nopcomp nocrtscts 192.1.1.1:192.1.1.25

    > "Silent" stops the system from sending PPP packets until the peer
    > starts first. Why is that needed?

    To wait for connections as a server should do.

    > "Nocrtscts" shouldn't be needed on a sync interface. Why was that
    > added?

    When things go wrong, you suspect all parameters :'(

    > > sent [LCP ConfReq id=0x1 ]

    >
    > You might want to include "default-asyncmap" to avoid negotiating this
    > parameter. (The parameter ought to do nothing, but perhaps it
    > confuses the peer.)

    I've tried that also

    > Everything else in the log appears to indicate that the PPP link
    > itself is working properly.
    >
    > I suspect that if you're having trouble, the problem isn't in PPP.
    > It's likely to be a confused peer or some sort of networking bug.
    >
    > --
    > James Carlson, KISS Network
    > Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    > MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677



  5. Re: ppp_generic escape character problem.

    Hi all,

    I think that I've found the mistake,

    In fact the ftp packets were not cut as I thought by interpretting
    control character. It was the the tcpdump. tcpdump (by default) cut
    packet with size is larger then 68 bytes.

    The bug was in the HDLC controler who replaces the last byte in a
    packet by 0x00, obviosly the IP checksum was erroneous and the kernel
    drop the packet silently.

    What surprise me, is that the ethereal tool don't indicate (by
    coloring) packets with checksum errors !!!

    Thank you all for your help.

    Younes.


  6. Re: ppp_generic escape character problem.

    behloul.maliste@gmail.com writes:
    > > You should not have to do such a thing, if the driver is properly
    > > constructed.

    >
    > What does a well constructed driver means for you ?


    It means that it obeys all of the applicable standards, provides
    interfaces that conform to the software around it, and doesn't have
    egregious bugs.

    > I've suspected that also: the pppd ask for many IOCTL, but the
    > documentation /Documentation/networking/ppp_generic.txt doesn't explain
    > that, so I tried to emulate it like it's done in irnet_ppp.c (PPP over
    > Irda)


    That doesn't sound quite right to me. IRDA is async, isn't it?

    I'm certainly no Linux expert, but I would have expected this to
    emulate a synchronous port and work with ppp_synctty.c.

    In general, sync ports are extremely simple. Few if any of the ioctls
    matter. It's just HDLC packets in and out.

    > > > target:~# pppd /dev/ppp_isdn -detach sync ktune local silent debug
    > > > kdebug 7 nopcomp nocrtscts 192.1.1.1:192.1.1.25

    > > "Silent" stops the system from sending PPP packets until the peer
    > > starts first. Why is that needed?

    > To wait for connections as a server should do.


    That's normally done by using DCD -- the open() call should block
    until "carrier" (meaning a call) is present.

    In any event, the fact that you're able to get the link up to me means
    that it's not very likely that there is a PPP problem here. It sounds
    like you're having some sort of networking or application problem.

    PPP links typically don't fail in the way you've described. You said
    that your file transfers are truncated, correct? That's not the sort
    of failure I'd expect if something were wrong with PPP, regardless of
    the type of link in use. If it were a PPP problem, I'd expect the
    transfers would just _hang_ or time out. A "successful" transfer that
    provides a corrupt file points to problems elsewhere.

    One thing that could potentially cause this sort of problem would be
    poor buffer management in the underlying driver. It's a remote
    possibility, but since you're working with a custom driver, just about
    anything is possible, and it's hard to guess.

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

  7. Re: ppp_generic escape character problem.

    behloul.maliste@gmail.com writes:
    > The bug was in the HDLC controler who replaces the last byte in a
    > packet by 0x00, obviosly the IP checksum was erroneous and the kernel
    > drop the packet silently.


    Yikes! That's a really serious bug.

    > What surprise me, is that the ethereal tool don't indicate (by
    > coloring) packets with checksum errors !!!


    It can only do that if the whole packet is captured. See the "-s
    snaplen" option.

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

+ Reply to Thread