PPP Flag Sequence

[Federico Frigo]

Hi there, I'm trying to connect my RaspberryPi to an FTDI chip. They communicate over serial, and they use PPP as underlying protocol. I'm able to make them communicate, but the FTDI implementation is quite buggy, so I'm having some trubles with the Flag Sequence, since the FTDI chip wants it at the beginning of every package that it receives.

I'm using the pppd package, i tried to modify it to achive my needs but it was a failure, and now I'm wondering if I have to modify the Linux kernel to do so or if I have to simply modify the pppd package.

Is there someone who can point me to the right direction?

Thanks!

[Rob van der Putten]

Hi there

This way to fuzzy.
Which FTDI chip do you mean?
And as far as I know the Flag Sequence (01111110 / 0x7e / '~') is always
there. You can disable or enable Van Jacobson TCP/IP Header Compression
though.
AFAIK the Raspberry Pi serial port doesn't have RTS and CTS. Without
those you may lose data at high speeds.
And USB to serial converters can be quite buggy. Some may drop an odd
byte here and there. That will mess up your PPP.


Regards,
Rob

[Federico Frigo]

I know for sure that not all ppp packets are sent with the leading '~', in fact I found this in the linux kernel on RaspberryPi GitHub repo: https://github.com/raspberrypi/linux/blob/rpi-5.10.y/drivers/net/ppp/ppp_async.c#L560

As you can see, on timing basis, the leading flag sequence is not inserted. So maybe I have to patch this file to make it put the '~' on each packet no matter what, ain't it?

[Rob van der Putten]

Hi there

Without wading through the entire source code, I expect this to be
~Packet~Packet~, vs ~Packet~~Packet~. Both are OK. ~PacketPacket~ is
not! Synchronous PPP will send ~~~~~ when idle, asynchronous PPP will not.
Linux has a freaky optimization in the LCP ping. It will only send a LCP
ping when there hasn't been any other data for some time.
Furthermore, the number of config requests in one LCP packet may vary.
A PPP implementation without '~' at packet boundaries seems broken to me
(See RFC). Are you this is what is happening? Make a raw data dump.

Again, RasPi serial ports are broken. USB-Serial converters are broken.
They do drop bytes (including '~'). Use decent serial hardware or use
Ethernet for TCP/IP.

And you still haven't explained what you are trying to do. Draw some
ASCII art.


Regards,
Rob

[Federico Frigo]

Oh ok, now I got this clear in my mind.

Without taking too much time on diagrams or long explanation, I just want to force the PPP to always send packets like this:
~Packet~~Packet~~Packet~
So that all packets always have their own leading and trailing '~'.

This is because PPP stack on the other end is buggy (it's a custom implementation that unfortunately I cannot fix), and if it gets packets in the form of:
~Packet~Packet~Packet~
it crashes and shut down the connection.

I know this way is absolutely not optimized but I unfortunately don't have other options.

[Rob van der Putten]

Hi there


On 02/02/2021 15:36, Federico Frigo wrote:

<Cut>

> Oh ok, now I got this clear in my mind.
>
> Without taking too much time on diagrams or long explanation, I just
> want to force the PPP to always send packets like this:
> ~Packet~~Packet~~Packet~
> So that all packets always have their own leading and trailing '~'.
>
> This is because PPP stack on the other end is buggy (it's a custom
> implementation that unfortunately I cannot fix), and if it gets
> packets in the form of:
> ~Packet~Packet~Packet~
> it crashes and shut down the connection.
>
> I know this way is absolutely not optimized but I unfortunately
> don't have other options.

Patch the source or pipe PPP through some process that adds '~'.


Regards,
Rob

[Federico Frigo]

I think i'll patch the kernel, so it'll be easier to keep under control this feature. Thanks a lot Rob, for helping me and for your quick answer! I really appreciated that.

Best regards,
Federico

[Tauno Voipio]

The HDLC flag is a part of the PPP encapsulation for serial line,
see RFC1662.

It is not a property of the FTDI chip, unless you can prove
that the flag is spoiled by the chip in some way.
The flag (0x7e) is needed to delimit the PPP packets.

--

-TV

[Federico Frigo]

Just to update you guys that helped me out and for everyone looking for answers about this problem, this is how I worked this out:
- pppd package leverage on ppp module inside linux kernel in case of Debian distros for most of its operations (like, in my case, ppp packet encapsulation)
- in case of solaris os, most of the code (don't know if all of it) is contained in pppd package itself

Depending on your case, you need to modify either linux kernel or pppd package. In my case I had to modify Raspberry Pi OS kernel (https://github.com/raspberrypi/linux), then I had to build it and mount it on Raspberry Pi SD following their guide (https://www.raspberrypi.org/documentation/linux/kernel/building.md). Now everything is working like a charm.
Thanks again guys!
Sincerely,

Federico

[Rob van der Putten]

Hi there

Perhaps you can turn it into a config option and supply a patch.


Regards,
Rob

[Federico Frigo]

Hi again, I found out that flag_time is a module parameter in linux kernel (see: https://github.com/torvalds/linux/blob/master/drivers/net/ppp/ppp_async.c#L88), so my guess is that is possible to set its value from the outside somehow (i read this guide about that: https://tldp.org/LDP/lkmpg/2.6/html/x323.html).

If this is the case, then it should be possible to add this feature directly to pppd module instead of editing linux kernel; the problem is that I don't know how to do this... Could you maybe point me to the right direction?

Thanks!

[Federico Frigo]

Some updates: I managed to make this work by manually loading the ppp_async kernel module passing the flag_time=0 parameter to it before starting pppd, like this:

sudo modprobe ppp_async flag_time=0

This could be obviously much easier if it can be converted to an options option, something like FLAG_TIME that can be set to an integer, then pppd takes care of loading it.

Again, I can do that, but I need some help to understand from where to start 😁

[Giovanni]

On 02/16/2021 12:56 PM, Federico Frigo wrote:
> Some updates: I managed to make this work by manually loading the
> ppp_async kernel module passing the flag_time=0 parameter to it
> before starting pppd, like this:
>
> sudo modprobe ppp_async flag_time=0
>
> This could be obviously much easier if it can be converted to an
> options option, something like FLAG_TIME that can be set to an
> integer, then pppd takes care of loading it.

flag_time is already an option for ppp_async and you can load it
automatically entering a line:

options ppp_async flag_time=0

in a file with the extension .conf created in the directory
/etc/modprobe.d/

Ciao
Giovanni
--
A computer is like an air conditioner,
it stops working when you open Windows.
< http://giovanni.homelinux.net/ >

[Henning Hucke]

On 2021-02-16, Federico Frigo <ffr...@gmail.com> wrote:

> [...]

> Again, I can do that, but I need some help to understand from where to start 😁

# ( modinfo ppp_async | less -S ) && man modprobe.d

You are not too familiar with the kernel module system, aren't you?
SMILEY! -> :-)

Best regards
Henning Hucke
--
"nobody is perfect."
-- Nobody ;)

[Henning Hucke]

On 2021-02-16, Federico Frigo <ffr...@gmail.com> wrote:

> [...]

> Again, I can do that, but I need some help to understand from where to start 😁

# ( modinfo ppp_async | less -S ) && man modprobe.d

You are not too familiar with the kernel module system, aren't you?
SMILEY! -> :-)

Best regards

Henning (nobody) Hucke