accel-pppd version 1.12.0 - problem with PPPoE initialization while clients are waiting to connect

[MarcinKabiesz]

Hello,
I have this problem and I don't know if anyone reported it to you or not, but it's hard to detect it when you're inactive.

[1] when starting a server with PPPoE support, when a significant number of PPPoE clients are waiting to connect to it, there is a problem with the initialization of vlan interfaces

This problem is interesting or strange because we must meet two conditions: have several/a dozen or so vlan interfaces with a group of PPPoE clients waiting to be connected (mainly MikroTik or UBNT or, less often, Windows or Linux), and additionally, there must be at least active on each interface. a dozen or so waiting sessions for the presence of a PPPoE server, let's say 30-50 should be enough per interface

accel-pppd then very often fails to load the vlan interfaces completely or selectively and then in the accel-cmd console we see that we have 1 interface when there should be more of them but there are not... for some reason

then accel-pppd also reports a problem with communication on 127.0.0.1 with port 2001

I can fix it manually in 2 ways:

1 - run only on the physical ethX interface and run in a series of e.g. 5 interfaces, then wait a few seconds between each batch for a certain group of clients waiting for the PPPoE session to load.

2 - try to start the daemon again and hope that it will load all the required interfaces correctly and all waiting clients will log in to the accel-pppd server

[2] the earlier version did not require having interfaces in the file for the initialization of the entire accel-pppd engine with the PPPoE module

it was then convenient for the automation which, on the so-called demand, executed the command to add or remove an interface from PPPoE using the command accel-cmd pppoe interface add ethX.xx or accel-cmd pppoe interface del ethX.xx

It may not be a bad approach that requires having an interface in the file as a definition to be able to add an interface to support a given module, in my case it is PPPoE, but the problem is the fact from point 1 that starting a large number of interfaces when there are 500-1000 PPPoE sessions on the accel-pppd server becomes a problem...

I then have to manually activate 1 interface, then upload a file with the full definition of the interfaces I want to use, and then use a script to manually send commands in batches, e.g. of 5 pieces, to add new interfaces between which I have to introduce a delay waiting until a number of people/sessions connect to my network. server so that I could continue working

Another problem, as I noticed, is having a VPN tunnel together with PPPoE in Accel-PPPd, e.g. PPtP. When PPPoE sessions work properly, but I need to log in to the PPtP VPN tunnel and for some unexplained reasons (in my opinion, the server expects a known client IP address), the entire Accel-PPPd server crashes, not just this 1 module, which is currently PPtP. This phenomenon can mainly occur when a service scanning bot detects a given service, e.g. VPN PPtP, and I try to connect to it, and at that moment the entire Accel-PPPd server crashes and I am forced to restart it, and therefore when using multiple interfaces with a vlan for an additional condition in the event that the server stops working when it serves a significant number of clients and has many interfaces on which a given service must be active.

[DmitriyEshenko]

Hi @MarcinKabiesz you describe really terrible things. First of all you have to capture all logs with debug level and provide config (mask private fields like public IP / secrets / passwords). Then check also core.log and emerge.log. If you have no overlapped IPs, try to verifu systemd-udev setting
https://docs.accel-ppp.org/guides/BRAS_tuning.html#hotplug-optimization
https://docs.accel-ppp.org/guides/BRAS_tuning.html#systemd-udev-optimizations

As for PPTP, in this case you need to build accel-ppp in debug and get coredump
https://docs.accel-ppp.org/debugging/index.html#debugging

[MarcinKabiesz]

Hello @DmitriyEshenko ,
I will try to prepare the data for verification for you.

1. I don't use systemd - it adds unnecessary garbage to my network management and causes limitations and additional load, that's why I use sysvinit
2. udev from Gentoo is used
3. I am currently using Gentoo, but previously I was using my own proprietary system compiled with LinuxFromScratch

Praise for a successful product that, in my opinion, beats this crap called PPP. Your application is much more efficient and lighter to handle many sets of sessions simultaneously, while PPP unfortunately causes a very large performance overhead and load on the router, which is unacceptable for us.

Thanks again and please don't abandon the product because it is very, very good in my opinion and it was difficult to find you before, but I found it and I use it.

Unfortunately, you still have stability problems, but the application itself is going in the right direction, so keep developing it because it has high potential.

:)

Best Regards

[MarcinKabiesz]

Hello @DmitriyEshenko,
I come with more news. Sorry for taking so long but I want to give you my accumulated knowledge about the correctness and stability of your software as honestly as possible.

So:

1. the problem of instability of pppoe session login after accel start/restart mainly depends on if-up/if-down scripts. These scripts are not mine but attached to the Gentoo system, among others those from /etc/ppp/ip-up.d / ip-down.d named 30-wins.sh, 40-dns.sh, 50-initd.sh attached in the ip-up and ip-down variable in the pppd-compat section. disabling these variables caused that accel does not crash now. I think that with the crowd of clients trying to log into the system, these scripts must show some instability, e.g. sending the exit(1 to 255) code instead of exit(0) and or the script sending the exit/die signal. during the server crash I noticed that only the main accel process and the process responsible for calling the ip-up script remained in the processes. These scripts are the default gentoo scripts so you can determine what they look like and map my environment.

2. with a large number of client logins, accel quite strongly shows the D(delay) state in its login threads. Additionally, this causes a sudden increase in the system load in the load information. At this point, udevd also shows a fork of its processes to build probably its pppoeX interfaces where X is the interface number, also during increased login traffic and blocked processes in the D(delay) state, the accel-cmd command waits for one of the processes to unblock itself, which is why not all executed accel-cmd commands, e.g. show sessions or show interfaces, are able to show the current status of accel operation. I would suggest, if this is not currently the case, to separate accel-cmd from client login threads so that regardless of whether I have a flood of new client sessions or not, I can check the current status of accel

3. before version accel 1.12, it was possible to add interfaces to the pppoe section on which accel should listen for the pppoe concentrator without having to add them. currently, I am forced to add the interface to the file before adding the interface, i.e. raising it so that clients on a given interface can see my concentrator, then execute the command accel-cmd pppoe interface add eth0.xx then only it works, previously I could do it dynamically. if I am forced to use the file in the current version to declare it before adding the interface, could I not add the include option? with the file that I will build dynamically. currently it is inconvenient when I have to build the entire /etc/accel-ppp.conf file and in fact I add or remove the interface variable from it in the pppoe section

I think you should implement these corrections right away. I tried to list them in order of importance of the problem 1 - critical, 3 - optional but welcome.

If you do not want to use the fix publicly, you can send me the new fixed code, then I will try to compile it and test for you whether the given code fix works according to expectations and stability of the accel program.

Remember, you are making a great program that beats by an order of magnitude in relation to this prehistory used to this day under the name pppdaemon. You have great potential, but the errors still exist in it. :)

Best Regards