ppp_generic escape character problem.

[b***@gmail.com]

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 <magic 0x7ef415d7> <pcomp> <accomp> <callback
CBCP>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x15f89038> <accomp>]
sent [LCP ConfRej id=0x1 <pcomp> <callback CBCP>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x15f89038> <accomp>]
rcvd [LCP ConfReq id=0x2 <magic 0x7ef415d7> <accomp>]
sent [LCP ConfAck id=0x2 <magic 0x7ef415d7> <accomp>]
sent [LCP EchoReq id=0x0 magic=0x15f89038]
kernel does not support PPP filtering
sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 192.1.1.1>]
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 <compress VJ 0f 01> <addr 0.0.0.0> <ms-dns1
0.0.0.0> <ms-wins 0.0.0.0> <ms-dns3 0.0.0.0> <ms-wins 0.0.0.0>]
sent [IPCP ConfRej id=0x5 <ms-dns1 0.0.0.0> <ms-wins 0.0.0.0> <ms-dns3
0.0.0.0> <ms-wins 0.0.0.0>]
rcvd [IPCP ConfAck id=0x1 <compress VJ 0f 01> <addr 192.1.1.1>]
rcvd [IPCP ConfReq id=0x6 <compress VJ 0f 01> <addr 0.0.0.0>]
sent [IPCP ConfNak id=0x6 <addr 192.1.1.25>]
rcvd [IPCP ConfReq id=0x7 <compress VJ 0f 01> <addr 192.1.1.25>]
sent [IPCP ConfAck id=0x7 <compress VJ 0f 01> <addr 192.1.1.25>]
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 ###########################

[James Carlson]

Post by b***@gmail.com
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).

Post by b***@gmail.com
in async mode a map is used to indicate to peers witch character to
escape or not, but I don't need that ?

Correct.

Post by b***@gmail.com
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.

Post by b***@gmail.com
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?

Post by b***@gmail.com
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x15f89038> <accomp>]

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.

[b***@gmail.com]

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

Post by James Carlson

Post by b***@gmail.com
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)

Post by James Carlson

Post by b***@gmail.com
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.

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

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

Post by James Carlson

Post by b***@gmail.com
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x15f89038> <accomp>]

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

Post by James Carlson
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.
--
Sun Microsystems / 1 Network Drive 71.232W Vox [phone]
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax [phone]

[James Carlson]

Post by b***@gmail.com

Post by James Carlson
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.

Post by b***@gmail.com
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.

Post by b***@gmail.com

Post by James Carlson

Post by b***@gmail.com
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.

[Unruh]

Post by b***@gmail.com
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.

Post by b***@gmail.com
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).

Post by b***@gmail.com
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 <magic 0x7ef415d7> <pcomp> <accomp> <callback
CBCP>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x15f89038> <accomp>]
sent [LCP ConfRej id=0x1 <pcomp> <callback CBCP>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x15f89038> <accomp>]
rcvd [LCP ConfReq id=0x2 <magic 0x7ef415d7> <accomp>]
sent [LCP ConfAck id=0x2 <magic 0x7ef415d7> <accomp>]
sent [LCP EchoReq id=0x0 magic=0x15f89038]
kernel does not support PPP filtering
sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 192.1.1.1>]
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 <compress VJ 0f 01> <addr 0.0.0.0> <ms-dns1
0.0.0.0> <ms-wins 0.0.0.0> <ms-dns3 0.0.0.0> <ms-wins 0.0.0.0>]
sent [IPCP ConfRej id=0x5 <ms-dns1 0.0.0.0> <ms-wins 0.0.0.0> <ms-dns3
0.0.0.0> <ms-wins 0.0.0.0>]
rcvd [IPCP ConfAck id=0x1 <compress VJ 0f 01> <addr 192.1.1.1>]
rcvd [IPCP ConfReq id=0x6 <compress VJ 0f 01> <addr 0.0.0.0>]
sent [IPCP ConfNak id=0x6 <addr 192.1.1.25>]
rcvd [IPCP ConfReq id=0x7 <compress VJ 0f 01> <addr 192.1.1.25>]
sent [IPCP ConfAck id=0x7 <compress VJ 0f 01> <addr 192.1.1.25>]
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 ###########################

[b***@gmail.com]

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.

[James Carlson]

Post by b***@gmail.com
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.

Post by b***@gmail.com
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.