ppp compression is not enabled - how to debug

[rsend]

Hi,
I'm building a ppp connection over a slow, high latency radio link and I'm having some issues with enabling compression. In short, the host end is Raspberry Pi Zero (Bullseye, kernel 5.10 with ppp 2.4.9 I think) talking via a USB-Serial adapter to a 900Mhz radio. On the other end is a Netgear R6220 router running dd-wrt (MIPS, kernel 4.14 with ppp 2.4.8), talking to it's radio via the same USB-Serial adapter (both Prolific PL2303).

The only way I can make it work so far is to use the "noccp" option, which is unfortunate because the link is very slow and compression makes a significant difference.

If I don't specify "noccp", the symptom is that compression negotiation appears to go into an infinite loop, as follows:

sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>] rcvd [CCP ConfReq id=0x3 <mppe -H -M -S -L -D -C> <deflate 15> <deflate(old#) 15> <bsd v1 15>] sent [CCP ConfRej id=0x3 <mppe -H -M -S -L -D -C> rcvd [CCP ConfAck id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>] sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>] rcvd [CCP ConfReq id=0x3 <mppe -H -M -S -L -D -C> <deflate 15> <deflate(old#) 15> <bsd v1 15>] sent [CCP ConfRej id=0x3 <mppe -H -M -S -L -D -C>] rcvd [CCP ConfAck id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>] sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>] rcvd [CCP ConfAck id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>] rcvd [CCP ConfReq id=0x3 <mppe -H -M -S -L -D -C> <deflate 15> <deflate(old#) 15> <bsd v1 15>] sent [CCP ConfRej id=0x3 <mppe -H -M -S -L -D -C>] ......

When I connect the host Raspberry Pi to a PC running the same pppd invocation (but ALSO v 2.4.9) , compression is enabled as expected.

What should I check for here? Or, is there any kind of known issue in talking between 2.4.8 and 2.4.9?

Thanks,
R

[Neustradamus]

@paulusmack, @enaess: Have you seen this ticket?

[enaess]

@rsend

Would you be able to upgrade to the latest on at least either side, i.e. upgrade to pppd-2.5.0?

Also, please attach the configuration you have, and add some line feeds between each line:

sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>] 
rcvd [CCP ConfReq id=0x3 <mppe -H -M -S -L -D -C> <deflate 15> <deflate(old#) 15> <bsd v1 15>] 
sent [CCP ConfRej id=0x3 <mppe -H -M -S -L -D -C>
rcvd [CCP ConfAck id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>] 
sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>] 
rcvd [CCP ConfReq id=0x3 <mppe -H -M -S -L -D -C> <deflate 15> <deflate(old#) 15> <bsd v1 15>] 
sent [CCP ConfRej id=0x3 <mppe -H -M -S -L -D -C>] 
rcvd [CCP ConfAck id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>] 
sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>] 
rcvd [CCP ConfAck id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>] 
rcvd [CCP ConfReq id=0x3 <mppe -H -M -S -L -D -C> <deflate 15> <deflate(old#) 15> <bsd v1 15>] 
sent [CCP ConfRej id=0x3 <mppe -H -M -S -L -D -C>]

Generally, this does look like a bug to me. The two peers should be able to converge on using one of <deflate 15> <deflate(old#) 15> <bsd v1 15>, and the peer with id=0x3 should remove the MS MPPE from the requested list of advertised compression in the subsequent transmissions as the peer with id=0x1 rejected it.

[rsend]

Sorry about the formatting - I put it as "code" and that's how it came out.

FWIW I forgot to add some possibly indicative information, the dd-wrt (mips) side reports over and over again:

ppp0: compressor dropped pkt

And no, I don't think I can upgrade either end. The dd-wrt side is tied to a package manager they call Entware, for which the pppd package has these notes:
https://github.com/Entware/Entware/blob/master/package/network/services/ppp/Makefile#L7

Actually, those guys did say "Just use dd-wrt toolchain" - does that mean I SHOULD be able to build a new version myself without rebuilding kernel? dd-wrt is not "exactly" user friendly - building the whole thing from scratch oneself isn't really supported. I had opened this question over there:

Entware/Entware#935

I did try one other indicative thing, I downgraded the Raspberry Pi side to 2.4.7 by installing an older version of Buster, same error against dd-wrt but fine against a PC.

Will add my invocation later. Thanks for checking, so far!

[enaess]

I think pppd-2.5.0 support is in progress, see here:
openwrt/openwrt#12848

I've never compiled or loaded it onto a openwrt device before. The problem with pppd is that there are many downstream projects dependent on pppd, so those will require a recompile as well. Your best bet would be to upgrade to the new OpenWRT firmware with the latest pppd-2.5.0 when it is ready. 🤷

Once you have time, it would be easier if you are able to describe in detail what is working and what is not. I think you have me lost somewhere in the weeds...

[paulusmack]

It would be useful to see the timestamps on the packets. That might illuminate why we send another ConfReq after getting a ConfAck.

Could the latency of the radio link be 1.5 seconds or greater, in each direction? If so then you probably want to increase the retransmission time to be more than 2 * latency.

[rsend]

@enaess OpenWRT and dd-wrt are very different things - I haven't tried OpenWRT yet. But maybe that will solve the problem, even on their current version which is more recent than the dd-wrt one! Will attempt and report back.

@paulusmack latency COULD be greater than 1.5 sec. I've seen 12 seconds pings on occasion (!), but that would be weird in my test setup - the radios are both sitting next to me and pings are usually ~ 200ms. Either way, where can I adjust this parameter?

[Neustradamus]

@enaess, @paulusmack: Have you seen the latest @rsend comment?

[paulusmack]

@paulusmack latency COULD be greater than 1.5 sec. I've seen 12 seconds pings on occasion (!), but that would be weird in my test setup - the radios are both sitting next to me and pings are usually ~ 200ms. Either way, where can I adjust this parameter?

Unfortunately there doesn't appear to be a way to change it for CCP short of changing the source code and recompiling (changing DEFTIMEOUT in pppd.h would change it for all protocols, or set ccp_fsm[0].timeouttime in pppd/ccp.c to change it for just CCP). There is the 'lcp-restart' parameter which sets it for LCP, 'ipcp-restart' for IPCP, etc.