PPPoE adaptive LCP echo support

Hello,

I’m looking at moving from OPNsense (not a huge FreeBSD fan with the way in which it handles F/W connection states) to trying IPfire ( Much prefer Linux based F/W), and found that by default IPfire launches pppd with lcp echo with below option’s lcp-echo-interval 20 lcp-echo-failure 5, as below;

[root@ipfire ~]# ps -ef | egrep -ai ppp
egrep: warning: egrep is obsolescent; using grep -E
root      2051     1  0 10:11 ?        00:00:00 /usr/sbin/pppd plugin pppoe.so red0 usepeerdns defaultroute noipdefault noauth default-asyncmap hide-password nodetach noipv6 noaccomp nodeflate nopcomp novj novjccomp nobsdcomp user username@example.com lcp-echo-interval 20 lcp-echo-failure 5 -pap debug

This results in LCP echo requests always being sent even when the WAN PPPoE interface is active and receiving traffic.

pppd supports adaptive LCP by additionally using the lcp-echo-adaptive option → pppd(8) - Linux manual page

       lcp-echo-adaptive
              If this option is used with the lcp-echo-failure option
              then pppd will send LCP echo-request frames only if no
              traffic was received from the peer since the last
              echo-request was sent.

I see the lcp-echo-adaptive option appears as available in the IPfire pppd implementation as below

[root@ipfire ~]# pppd show-options
LCP Options:
    lcp-echo-adaptive      Suppress LCP echo requests if traffic was received

However i could not find any IPfire GUI option to enable lcp-echo-adaptive option.

Can this option be added to IPfire option in System → Dialup ?

Currently using / evaluating IPFire 2.29 (x86_64) - Core-Update 198

Thanks in advance …

i added the option lcp-echo-adaptive to the file /etc/ppp/options, and conducted some testing, and found this works…lcp echo request’s are sent adaptively now…

Would sure be nice if the option could be user selectively added via the GUI….

1 Like

Hello,

I am sure we can change to this as a default. I am not sure if it actually has a very big positive impact as the keepalive packets will probably not consume a lot of bandwidth.

2 Likes

All done.

3 Likes

regarding "tcp_fin_timeout" :red_question_mark:
or can you name it :man_shrugging:

i wans’t referring to OPNsense/FreeBSD "tcp_fin_timeout", there has always been an unresolved issue with OPNsense/FreeBSD listing incorrect rules in firewall sessions, after a reboot, or upgrade, or after altering firewall rules. The only workaround is to delete the entire F/W state after such events, which destroys all F/W states….

It’s already been discussed in verbatim with maintainers/contributors, and there are zero plans to fix it, many people rightly, complain about it all the time…

Plus i’ve always been a linux fanboy, starting all they way back in the 90’s when Red Hat was released, and have much greater trust in Linux than FreeBSD….

3 Likes