Why accel-ppp needs to be rewritten in Rust — evidence from our own git history

[svlobanov]

I'd like to make the case for rewriting accel-ppp in Rust. This is not a "rewrites are fashionable" post. Everything below comes from our own repository: ~2,400 commits between 2009 and 2026, ~80,000 lines of C, and commit hashes you can check yourself. The short version: for 17 years, a huge share of our engineering time has gone into fixing the same handful of bug classes that C makes trivially easy to write and hard to find. Rust makes these classes impossible by construction.

1. What the history actually says

Out of 2,403 commits, 719 have "fix" in the title. That's one commit in three. Now filter by the bug class named in the title (a strict undercount - it only catches what the author happened to write in one line):

Bug class	Commits with the class in the title
Race conditions	27
Memory leaks	25
Crashes / segfaults	24 + 13
Buffer overflows	21
Uninitialized memory	11
Use-after-free	8

That's ~130 commits whose headline is a memory-safety or data-race bug - and the titles undersell it badly, because single commits fix batches of such bugs. 62f77400 ("Fixed some errors found by valgrind and pvs-studio", 2021) alone fixes, by PVS-Studio's count: uninitialized pointers, null dereferences, memory leaks, a function that exits while holding pthread_spin_unlock, and ~40 instances of void * arithmetic. Every one of those reached users before an analyzer spotted it.

Nobody in this project has ever been careless. The same names - Dmitry, Themiron, Guillaume Nault, Denis, nuclearcat - fix these things fast and well. The point is that C lets careful people ship these bugs anyway, and the project pays for it forever.

2. Case files

Here are the ones I find most instructive.

2.1. Remotely triggerable memory corruption in L2TP (2020)

2324bcd5 - l2tp: fix RCE through buffer overflow. Insufficient validation of the L2TP header length and AVP length allowed a remote, unauthenticated packet to overflow a buffer - reported by external security researchers (Chaitin Security Research Lab). The same commit also fixed LE/BE compatibility: the header used C bitfields, whose ordering is implementation-defined, so the parser simply misread every field on big-endian machines.

Read that again: one bug, three C-specific root causes - manual length checking that was one if short, bitfields whose layout the language refuses to define, and endianness handled by hand.

2.2. uint8_t *calling[254] (2025)

2bbf451b - l2tp: fix buffer overflow and type errors in Calling/Called Number handling. The declaration

uint8_t *calling[254];

declares an array of 254 pointers, not 254 bytes. And since L2TP AVP values can be up to 1017 bytes, any peer sending a long Calling-Number overflowed the stack buffer. This landed in 2025 - fifteen years after the L2TP module was written, caught not by fuzzing but by someone reading the diff of a previous change. One stray asterisk, and the type system of C - which famously has a type system - says nothing.

2.3. RADIUS attribute parsing (2021)

d4cb8972 - buffer overflow when a RADIUS packet contains an invalid attribute length with attribute types ipv4addr, ipv6addr, ipv6prefix or ifid. Again: remote, again: unauthenticated, again: hand-rolled while loop over TLVs where one attribute-type branch forgot the length check. And again in 2026 in the same subsystem family: 22c61e8e, where split() returning 0 made dict_load read ptr[-1] - with the commit message noting, verbatim: "Triggering crash is compiler dependent, it might not happen now, but a bit different compiler, flags, and it might crash on load." That sentence is the entire argument against C in miniature: correctness that depends on the phase of the compiler's mood is not correctness.

2.4. Use-after-free: a recurring subscription, not an event

Look at the dates in this series:

• 1744cf7d (2014) - l2tp: use-after-free by tunnel context thread
• 3fa9e6ad (2016) - ppp_auth: possible use-after-free
• 22b24dc6 (2018) - ppp: use-after-free in ppp_auth_failed()
• c6667801 - triton: use-after-free in timer.c
• 7bd6843c (2026) - radius: "rad_req_free might free server in theory, and s will be invalid"
• 2ba4437b (2026) - pppoe: the mac-filter error path frees the entry and then keeps writing to it and links it into the list

Twenty-plus years of tooling, sanitizers in CI, and senior maintainers - and we were fixing use-after-free this year, in a code path triggered by a malformed line in a config file. In Rust this bug does not compile: the borrow checker rejects "free it, then keep using it" as a matter of grammar, not discipline.

2.5. When the optimizer is your enemy

287adbfc (2017) - triton crashed because GCC deleted the alloca() call entirely on any optimization level (the result was used indirectly, and the call is not observable in C's abstract machine). So the project crashed not because the code was wrong-looking, but because C's undefined-behavior rules license the compiler to remove code it "proves" unreachable. The same family: 2224396d, where signed integer overflow (undefined behavior in C) silently corrupted DHCPv4 address handling, and the bitfield/endianness bug from 2.1. Rust has no alloca, defines integer overflow semantics (checked in debug, wrapping-by-explicit-choice in release), and gives you u16::from_be_bytes instead of bitfield prayers.

2.6. Uninitialized memory, on the wire

29b90105 and c3710b6b - IPCP negotiated DNS and NBNS addresses containing uninitialized stack memory and handed them to peers. 62f77400 contains a valgrind trace of uninitialized bytes going out through sendmsg(). In C, "declare a struct, fill in most of the fields" compiles and runs and mostly works. In Rust there is no way to observe uninitialized memory through safe code, period.

2.7. The concurrency tax: triton

This is the systemic one. Accel-ppp's event framework, triton, is a hand-rolled world of contexts, threads, wakeup lists, and manual pthread locking. Its cost is visible across the whole history:

• 5ee3cf66 - shaper: fixed many race conditions (plural, in one commit)
• c709a126 (2018) - the schedule()/wakeup() race, where a wakeup could "write to invalid memory" and crash the daemon - fixed by redesigning the wakeup protocol, and the commit message candidly explains the API still must be paired and not nested by every caller, forever
• fd4bd103, 0bf9ca63, c7ad0e53, 37e2a417, 64f65c44, a77f4482, 61d91047, 80eab99d… the list goes on for 27 titles.

A PPPoE/L2TP daemon is a shared mutable state machine with dozens of concurrent sessions plus config reload plus CLI plus logging threads. In C, data races are invisible to the compiler - none of our warnings, sanitizers, or reviews can prove absence of races; they can only fail to find them. Rust's Send/Sync bounds and ownership model turn "this shared mutable state needs locking" into a compile-time error, and std::sync + channels (or async) replace triton's most fragile machinery with primitives that thousands of projects exercise daily.

3. The pattern

Notice what all these fixes have in common. In every case:

1. The buggy version compiled cleanly, passed review, and worked in testing.
2. The bug was latent - sometimes for years (uint8_t *calling[254] sat there for 15).
3. The fix is almost always a guard: one more length check, one more NULL check, one more lock, one more _safe list iterator (aa9e2eef literally swaps in list_for_each_safe after a segfault).
4. Then the next module re-introduces the same class, because nothing in C prevents it.

Our response so far has been to bolt on detectors - valgrind runs, PVS-Studio, cppcheck, ASan/UBSan in CI. These tools are valuable and I don't want to drop them. But every one of them finds instances after the bug exists, never classes before. The rust toolchain finds the class, at compile time, in every future commit, for free:

17 years of accel-ppp bug class	In Rust
Buffer overflow (21+ commits)	Bounds-checked slices; the calling[254] typo doesn't compile
Use-after-free / double free (8+)	Ownership; doesn't compile
Memory leaks (25)	RAII - Drop runs on every exit path, including error paths like 2ba4437b
Uninitialized memory (11)	Unobservable in safe code
Data races (27)	Send/Sync; shared mutability requires synchronization the compiler checks
UB surprises (alloca, signed overflow, bitfields, ptr[-1])	No alloca; overflow semantics defined; no raw bitfields; slicing can't go negative
Endianness (LE/BE bugs)	Explicit from_be_bytes/to_be_bytes everywhere

4. Beyond memory safety

A rewrite buys more than the borrow checker:

• Fuzzing as a first-class citizen. We parse untrusted packets for a living - L2TP, PPTP, PPPoE, DHCPv4/v6, RADIUS, SSTP. cargo-fuzz gives per-target coverage-guided fuzzing in a few lines; today standing up the equivalent for our C parsers is a project of its own. Fuzzing safe Rust finds logic bugs, not memory corruption - a completely different (and much cheaper) triage experience.
• The accelerator we're missing is contributors. accel-ppp is maintained by a small, heroic group. Rust's ecosystem (crates.io, clippy, rustfmt, built-in unit tests, cargo test in every CI) lowers the barrier for a new contributor to be correct, and clippy catches entire review categories. The network-daemon-in-Rust pattern is well proven by now; we are not pioneers taking a risk, we are late adopters eliminating one.
• Tooling modernization comes with the rewrite. Compare our hand-maintained configure/CMake dance across five OS containers with cargo build and cargo vendor. Compare accel-cmd: on this very branch, 774 lines of legacy C (legacy/accel_cmd.c) became ~750 lines of Rust including a real test suite (src/tests.rs) that the C version never had. Same protocol, same features, safer and tested - that's the proof of concept, and it's already in-tree.
• Performance is not the trade-off people fear. Rust is ahead-of-time compiled, has no GC, and its zero-cost abstractions (iterators, enums as tagged unions, Option instead of sentinel NULLs) generate code in the same class as C. For a daemon whose hot path is packet parse/mutate/serialize, the difference is noise; the wins - fearless refactoring of session state machines - are not.

5. Step zero: build the oracle first - massive AI-generated Python tests

Here is the part I want to insist on, because it changes the risk profile of the whole endeavor: before rewriting anything, we should generate a very large black-box test suite with AI assistance - in Python, not as C unit tests.

The reasoning:

• Unit tests in C are the wrong tool for a rewrite. They test the implementation, and the implementation is exactly what we're replacing. Tests bound to C internals (struct layouts, function calls) die with the C code and validate nothing afterwards.
• System-level Python tests are implementation-agnostic. Spin up the daemon, create veth pairs, feed it PPPoE/L2TP/DHCPv6 traffic, poke the CLI, kill sessions, reload config, assert on observable behavior: sessions established, RADIUS accounting emitted, addresses assigned, logs, accel-cmd show sessions. The same suite, unchanged, runs against the C daemon today and against the Rust daemon after each migration step. It is the oracle that makes "the rewrite behaves identically" a checkable claim instead of a hope.
• We already have the harness. tests/ is a pytest-based black-box suite with veth setup, dependency ordering and gcovr coverage - 18 test files today. That's the seed, not the finish line. The realistic target is to scale it by an order of magnitude or two, and that is exactly the kind of work AI is best at: mechanically enumerating scenario matrices (auth success/failure/timeout/reject, malformed and truncated packets per protocol, config permutations, session lifecycle races, reload-under-load) and writing the corresponding pytest code against an existing, well-defined harness.
• Run the generated suite against the C daemon FIRST. Every failure is either a test bug or a real accel-ppp bug - both are valuable; the second kind becomes the bug backlog. The passing runs record the golden behavior of the current daemon, quirks included, which we must reproduce (or consciously change) in Rust. An oracle captured before the rewrite is worth ten times the same oracle written afterwards, when there is no reference left to test against.

In short: the AI era lets us buy, cheaply, the thing every rewrite project historically lacked - an exhaustive behavioral snapshot of the old system. We should buy it before we need it.

6. The "Rust is harder to write" objection has expired

The classic argument against Rust for a project like this: steep learning curve, borrow-checker friction, slower feature velocity than "just write the C." That argument made sense when every line was typed by hand. It makes less sense every year, and I think it's already false:

• More and more code - especially in open source - is written with AI assistance, and that share is only growing. For a volunteer-maintained project like accel-ppp, this is not a sidebar; it is quickly becoming the default mode of contribution.
• AI assistants write Rust essentially as fluently and as fast as C. The syntax complexity of Rust - the thing the learning-curve argument was always about - is increasingly a tax paid by the model, not the human. The human reviews architecture and behavior; the model handles the Result plumbing and iterator gymnastics.
• And here is the important asymmetry: AI-generated C and AI-generated Rust carry very different risk. An AI writing C produces the same one-if-short length checks and free-then-use error paths we saw in section 2 - but at a new scale and speed, and polished enough to look right in review. An AI writing Rust produces code the borrow checker still refuses to compile if it's wrong about ownership, lifetimes, or data races. In other words, AI amplifies the case for Rust rather than weakening it: as code generation gets cheaper, machine-checked safety guarantees get more valuable, not less - because the bottleneck moves from "writing code" to "being sure about code," and being sure is precisely what C's toolchain cannot offer and Rust's compiler does by default.

So the honest comparison in 2026 is not "expert C velocity vs. slower Rust velocity." It is "AI-assisted C, where the memory-safety review burden stays on humans forever" vs. "AI-assisted Rust, where the compiler carries most of that burden for free."

7. The honest objections

• "Rewrites are where projects die." Big-bang rewrites, yes. Nobody proposes deleting accel-pppd next week. The realistic path is the one this branch already started: leaf components first (CLI done), then protocol parsers - where our worst bugs actually live - behind a stable FFI, then the session core, module by module, with the massively expanded black-box test suite from section 5 as the safety net under every step. The kernel modules in drivers/ stay C, of course - that's the kernel's world, not ours.
• "Good C programmers don't need this." Section 2 is 17 years of very good C programmers needing exactly this. The bugs above were written by the best contributors this project has ever had. That is not an indictment of them; it is the strongest possible indictment of the language.
• "Sanitizers and analyzers are enough." They run after the bug is written, they miss concurrency entirely, and every new line of C re-opens the exposure. The history shows we pay this tax in perpetuity.
• "Rust is too hard / slows contributors down." See section 6 - that trade-off has been inverted by AI-assisted development, and the accel-cmd experiment in-tree shows the workflow already works here.

8. Proposal

1. Build the oracle first. Use AI to massively expand the black-box Python test suite (section 5), run it against the current C daemon, fix or file the failures, and record the golden behavior.
2. Keep accel-cmd (Rust) as the template; land it.
3. Set up the hybrid build (already sketched in accel-cmd/build.rs) and CI for mixed C/Rust.
4. Rewrite the wire-format parsers (L2TP, PPTP, PPPoE, DHCP, RADIUS) in Rust with fuzz targets - these are where every remotely-triggered bug in our history lives - and verify each one against the oracle suite.
5. Replace triton's threading core with a safe concurrency model, module by module.
6. Freeze feature work in C modules as they're migrated; users see no protocol changes.

I'm not saying this is small. I'm saying the alternative is 2bbf451b again in 2035 - another one-line typo in a hand-rolled parser, fifteen years latent, holding a remotely exploitable stack overflow, found by luck. The git history gives us the data; the data says the bug classes never stop. The only thing that stops a bug class is a compiler that refuses it.

[marekm72]

Just a few random thoughts (from someone with experience in C but not in Rust - not against Rust, but simply haven't learned it yet) - part of the problem is also high complexity, trying to do many things and support many different protocols instead of the simpler "do one thing and do it well".
PPPoE is what I use and is important for me to work. Fortunately, as a small local ISP I can reasonably trust customers to not try to hack my PPPoE server, and L2 access is not possible from the big bad Internet. PPTP and L2TP are considered insecure and obsolete, hopefully we don't need them anymore by the time the rewrite is done. IPoE - why do we need this, what does this do that standard IPv4/IPv6 DHCP can't?
Kernel modules probably are best upstreamed (already done for PPTP), not sure why vlan_mon can't be done in user space. Kernel modules also complicate packaging for Linux distros, and so do the dynamically loaded accel-ppp modules where I think it would be good to be able to simply link them statically and only enable the needed ones in config file. Linux kernel is written in C (yes I have heard of some new work in Rust, I'm neutral on that) and AI has recently been quite good at finding CVEs, should also help improve the current C codebase of accel-ppp.
Many code paths could be much simplified by not trying to handle malloc failures everywhere - just abort if it happens, see https://github.com/orgs/accel-ppp/discussions/162 - hopefully the reduced complexity will make other bugs easier to see.
No complier (C or Rust or any other) will catch subtle run-time protocol issues with misbehaving remote peers like my infamous Phicomm routers, only real world testing can find them.
I wish you all the best to succeed in the rewrite, but it's also a huge cost so I'm really not convinced either way.
EDIT - one more thing to consider, independent of C vs Rust - not sure how hard would be to implement privilege separation, like in OpenSSH - does all code really need to run as root? Especially the parts that parse untrusted data from the network.

[svlobanov]

as a small local ISP I can reasonably trust customers to not try to hack my PPPoE server

it is a mistake. even if your customers don't want to hack your pppoe server (which is also not quite the right approach to security), it might be an attacker using customer's infected CPE

[svlobanov]

L2TP

might be used with 3rd-party IPSeC software. L2TP+IPSEC is used nowadays

[svlobanov]

IPoE - why do we need this, what does this do that standard IPv4/IPv6 DHCP can't

accel-ppp IPoE is a session-based feature, it supports radius auth and accouting, shaping applying and some arp/nd-related stuff so it's not just yet-another dhcp-server. many ISPs around the world use IPoE instead of ATM-era PPPoX

[marekm72]

You're right, security of many cheap SOHO routers is poor, especially as customers want them for free so I bear the cost and have to use cheap ones (still try to choose OpenWrt-compatible hardware, so original firmware can be replaced if no longer updated by the Chinese manufacturer).

I do understand IPoE is also widely used by ISPs (though my use of PPPoE is not for legacy reasons, never had anything to do with ATM etc., it was all Ethernet and often bridged over WiFi from the start). It's just that I don't think all this should be in a single big process that does everything, adds complexity and makes bugs more difficult to find. For a rewrite (in C or Rust or some other language) I'd suggest to keep it simple and support PPPoE only. Then in another separate process support IPoE, etc. Some common library code could still be re-used.

The wakeup/schedule issue is likely due to poorly documented triton library (it appears internal to accel-ppp, or are there any other projects that also make use of it?), documentation in commit messages is not easy to find for someone who learns the code to do some work on it. The alloca thing you found is a real gem, isn't there a better way to do it? Even the alloca man page warns it's machine- and compiler-dependent. This is not just plain C code, it's C with lots of tricks that probably made sense to help performance back in early 2010s but also were risky as you have shown.