This is mentioned in https://github.com/vyos/vyos-documentation/blob/current/docs/changelog/1.3.rst as a fix in upcoming 1.3.9 - but the backport https://github.com/vyos/vyos-1x/pull/3015 had conflicts and was closed.
So, just a question - what is really the status of this in equuleus?

Is the binary file data/live-build-config/archives/zabbix-official-repo.key.chroot correct? Other key files there are text files.

BTW @SteveP these iperf speeds look quite impressive, I thought USB overhead would make it difficult to see much more than 1 Gbps in practice. Realtek was traditionally a "low cost, low performance" brand, it seems they have made a lot of progress...

Please make it possible to load the microde separately (file downloaded directly from CPU vendor, independent of VyOS update) to address the last edge case. Especially important for some Intel CPUs that self-destruct with too high voltage, as update applied too late will not reverse any permanent damage already done.

I think this can be marked as Resolved - can't say anything about 1.4, but 1.3 hasn't crashed for many months. Most likely fixed in upstream FRR. Thanks!

Thank you, though I wish I didn't have to, just have no choice. There are projects that already show how it should be done, better than I ever could. Some even offer choice of paid full supported or free basic unsupported version as pre-built VM appliance, or free full unsupported self-built from sources. Build process is documented, and they don't hate those who publish build scripts that make it easier. Please look at Xen Orchestra for example, management add-on for XCP-NG which is itself free (with optional commercial support) and stable at the same time, and the story how it started from Citrix XenServer was quite similar to how VyOS started from Vyatta. So yes, it can be done.

Sorry @syncer - I beg to differ.
It should be clear from the context that I mean the sagitta branch and at https://github.com/vyos it is no longer being updated.
I did participate, it's easy to find some evidence so I won't repeat it here, and all was well until a few months ago.
Only discovered and started using VyOS 1.2.x in 2020 (easy to check when I registered), not for 11 years. Earlier there was Vyatta, later EdgeOS on ERPro-8 for BGP, and MikrotTik as PPPoE server.
The only reason for moving to VyOS was non-commercial - wanted to enable IPv6, no customer asked or paid extra for it, it's just that I feel it was the right thing to do, but both EdgeOS and RouterOS had poor IPv6 support.
My business is a small local ISP for a few hundreds of people in a rural area, yes really that small and it's just me doing everything (no employees), not what you usually think when you see "ISP" (big companies with lots of money).
All IPv4 address space I use is 1024 addresses, easy to check in BGP (AS56523), and no CGNAT so each customer gets a single static IPv4, so you get the idea about the size of my business. My service costs about $15/month and I also provide some free services (for example to volunteer firefighters - Ochotnicza Straz Pozarna), also have two local schools in range but they were not interested (already have EU subsidized Orange fiber).
I never said I was smarter, and I don't understand what you mean by shit-talking. It's the first time ever in my life when I'm being accused of such things. Looks like some horrible misunderstanding.
If you mean something specific, please point me to it, and if it was indeed the case I will publicly apologize. Really I have no idea what you mean here.
But simply having some different opinions is not shit-talking. Actually I highly respect the Team for all the good work, it's just the last few months when things went horribly wrong in relations with some (not all) of you.
One more thing, I've been using Linux and other open source projects since 1994 (yes 30 years), and VyOS was the only ever open source project I supported with donations, $25/month from March 2022 to June 2024 when you stopped accepting them, and I did that voluntarily (didn't have to do it to get access to images, as I already had it granted as open source contributor).
So I hope you can see why I don't want to go away until we can talk like normal people and clear all the horrible misunderstandings.

It's not just me, there is significant interest in the community to do builds from source, and even in your own words @syncer https://vyos.dev/T6264#185011 it appears it was OK just a few months ago.
People took the challenge and have done some good work to make builds reasonably easy, complete with de-branding to address the tradermark concerns, and a few fixes in the build process.
As with any open source project, it's kind of natural to want to build from source. So I really don't understand all this hostility. I try to stay calm and not insult anyone, please try to do the same.
BTW, I try to contribute to some related projects (accel-ppp) and even though I'm strictly technical there (testing, reporting bugs, sending patches), issues are converted to discussions but that's all, just silence.
Let's stop fighting against each other and start some normal discussion (OK maybe here is not the best place, so I'll stop now). Peace.

@Viacheslav please, one of the free ways that I know and actually used was to build from source - and it's not updated anymore (moved to private repo). BTW, it''s still mentioned on the VyOS website, which is misleading. So this is very much related to this report, I'd like to build my own sagitta images using the new improved build system (hooray no more Jenkins!) but can't, it's not spamming just raising valid concerns. I don't care about pre-built LTS images anymore, just open the sources again so it is possible to build own images as before. Thank you.

The new build system is welcome, thank you. Restricted access to LTS sources, not so much...

@Viacheslav yes I do understand that, but why not just keep it Open here until then? BTW, this upstream has close ties to VyOS - see https://github.com/orgs/accel-ppp/people
But there is also the original author's repo, since 2010 - https://github.com/xebd/accel-ppp - the two seem to be developed in parallel, it's a bit of a mystery to me.
While I'm in the process of moving away from VyOS (because of the recent changes, updated LTS can't be built from source anymore), I still use accel-ppp and want to help.

Why wontfix? Does this mean that even if a fix will be available, you don't want to accept it? I'm slow but still working on it.

Upstream bug is still a bug, as long as VyOS includes accel-ppp, it is not RFC compliant - so why close it as Not Applicable? Are there plans to include some other PPPoE server implementation in VyOS?

The sound of silence, again... and I'm afraid it probably means confirmation. While technically this is compliant with the licenses (it is true what was said that the GPL doesn't require source code to be public, just available to those who get binaries), it loses one of the important advantages of Open Source - the "many eyes" - https://en.wikipedia.org/wiki/Linus%27s_law

@Apachez: This may be fine for new features, but some bugs may affect just the LTS releases (for example in the ISC DHCP server, replaced by Kea) or it may be necessary to test the fixes in production environment on LTS (or at least unofficial "LTS" rebuilt from source, which was an option for those without subscriptions for some time thanks to the good work of a few community members - it was fun while it lasted) which happens to be the case with one bug I've been working on (T4600). The bug turns out to be more complex than I first suspected, but I've already spent a lot of time on it, wanted to continue but didn't expect new hoops to jump through. I'm still running 1.3.8 from back when I had access (not anymore) and would like to test just changes to the one accel-ppp package without touching anything else that works otherwise, my setup is fairly complex and I'm not brave enough to try even 1.4.0 just yet, let alone rolling/circinus/stream whatever you name it.

That looks like a very much breaking change to me, not perfectly compatible. No more access to source code for LTS branches means it may not be possible to work on bug fixes (not just new functionality) anymore. So, to submit three PRs with bug fixes in the LTS branch to qualify for a subscription, one first needs to have a subscription. I don't think this will encourage more contributors to help the project. Is this intentional?

The fix is still work in progress, I need to dig deeper into accel-ppp history that predates the github repo. Not sure why some code was commented out over 10 years ago, IPV6CP restart timer is not stopped and disconnects in 3 seconds. Looking at older history in sourceforge but not sure if the answer is even there, sourceforge seems to have lost old history before 2011 (broken links).

Yes I am overloaded (who isn't), and yes I plan to make a PR but want to test it a bit more first, to be reasonably sure it causes no regression (potential resource leak if something allocated by the incomplete IPv6 configuration is not freed - not sure enough about accel-ppp internals). I'm working to rebuild replacement accel-ppp package (based on the same commit as in equuleus with just my patch applied, no other changes) and run it for a week or two while watching memory usage. Testing a fairly complex config in production environment, so not brave enough to try rolling or even sagitta just yet.

Not sure if still relevant after these years, as hardware has progressed to larger RAM sizes, but Debian x32 port doesn't seem to be very active anymore.

https://github.com/xebd/accel-ppp/pull/186

Hmmm... nothing before today in this task seems related to ddclient at all, isn't this task referenced by mistake?
BTW, does anyone know what happened that Debian un-released ddcilent 3.10.0-3 (reverted to 3.10.0-2.1)?

I think it's not yet ready for PR - needs review by someone more experienced with accel-ppp internals.
Issue already reported there - https://github.com/accel-ppp/accel-ppp/issues/57
Isn't upstream effectively the same now (accel-ppp owned by VyOS)?
Some issues I reported in accel-ppp were moved to discussions but met with silence otherwise. It might (or not, I don't know) have to do with some personal disagreements - someone other than me might have better luck.

Hello @dmbaturin - it's now about 2 years since I've discovered this bug, any chances to review my patch?
I don't claim it's 100% correct, in simple tests it does prevent LCP termination but the closing IPV6CP part (after "else") needs review by someone with better understanding of accel-ppp internals.
I still have a few users of these buggy routers in my network, can help with testing and possibly backporting the fix to Equuleus.
Thanks!

Would the project accept community contributions to Debianize more of the packages?
It is not clear what "no plans" really means - simply "no time for it right now, but community help is welcome" (understandable) or "we don't want it because ..." (please explain the reasons).

According to https://forum.vyos.io/t/building-rolling-apt-repo-with-deb-packages-from-source/14651/7 (I can't reply there - that thread is locked, and my account silenced) - "Jenkins build system is in process of deprecation."
This is news to me. Whatever the replacement will be, this feature request is not about deprecating Jenkins, but rather about Debianizing all of the source packages in the VyOS APT repo, in the same way some packages already are.
Search for *.dsc files in the current rolling-packages APT repo finds 21 of them, this is only a small part, it would be nice to see all packages there Debianized like this - this is what this feature request is about.
Then standard Debian tools can be used to rebuild *.deb packages from source packages. No need to search all of GitHub and assemble all parts.
Debian doesn't say "all source is in GitHub". Debian handles source packages as part of the standard packaging system. Debian is good. Please be like Debian. Thank you.

True, it is the user's responsibility to comply, no disagreement on that.
But a fairly simple change would make user's compliance easier, and it would be a win-win for everyone - why not?
Users who spend less time navigating a minefield of legal issues, could spend more doing useful things for the project.
It's not Invalid by any means. At least in my humble opinion - if you disagree, that's fine but please provide reasoned counter-arguments.

This was not about .deb packages in Debian itself, but from the VyOS APT repo used for building the rolling images.
Wishlist priority previously triaged (just 2 weeks ago) was fine, it's not Invalid - or at least have some civil discussion if we disagree on some points.
Quoting the GPL below, of course it's not legally required for other licenses like BSD, but still a good thing for any open source project anyway.

@blueish - thanks! Yes, apt-mirror works now - but will it continue to work with the new storage too?
BTW, good to see "deb-src" - but only a few source packages are in there. I think it would be great to have corresponding source for all these *.deb packages in the Debian source package format, then anyone who wants to contribute will be able to use dpkg-buildpackage to rebuild them.

I see. Thank you for explaining this.
Will this new storage continue to be public - or only for those with paid subscriptions?
If it will be public - will it be possible to mirror, to serve plain http to those who need it?

Many thanks. I think it was actually fixed earlier than 1.3.7 - I've been using VRF to allow SSH access only from a separate private management network, on a router that routes only public IP addresses (BGP, OSPF, PPPoE) otherwise, since about 1.3.5 or so.

Please consider making the microcode updates optional, and possible to load a specified file downloaded separately from the CPU vendor, independent of VyOS updates.
Some possible edge cases:

• running VyOS in a VM (microcode update has no effect in the guest anyway, needs to be done in the hypervisor)
• microcode update released in a hurry breaks something, need to revert to an older one
• microcode update reduces performance, doesn't improve security of VyOS (because it's not a typical multi-user system with untrusted users who can run any programs)
• microcode update has important fixes, but it will take time before a new LTS is released, or VyOS can't be updated because the subscription has expired

It would be useful for 1.4 as well, to be able to rebuild the LTS with local patches to some packages but otherwise unmodified, for example to make it easier to test bug fixes in a single package (such as accel-ppp https://vyos.dev/T4600 ) without much risk to introduce new bugs.

I can (carefully) say it's probably fixed in 1.3.x with newer FRR (compared to 1.2.x in the original report) - I've moved the two PPPoE servers to the same two boxes running BGP (still using OSPF to redistribute routes, at few hundreds of them scalability is probably not an issue yet that would require BGP) and they don't seem to crash anymore.
Not tested in 1.4.x yet - I may test it some time after the 1.4 final release, if I will still be able to get it.

If all of this would be done by the build script (download sources, apply patches, build binary packages and copy them to a local filesystem) there would be no problem.
I can't even see the list of packages in that 403 Forbidden repo - all of it blocked completely, not just access to binary packages.

OK, so where can I find the source (without the artwork) with the necessary patches and working build scripts (to build from the LTS, not rolling branch - just to be clear)? No problem to use my own CPU cycles and bandwidth and disk space, I can wait longer for the build to finish, sometimes (on sunny days) I even have some free electricity :) - in fact I would even prefer to build the binaries myself (of any packages not directly copied from Debian) rather than trust an external repo. And no problem, you've just got the 868th star from me, I simply didn't know this is something that matters. I have never distributed the LTS images to third parties, just using them internally. Yes, for some small scale production use (single-person business, running a very small local ISP for a few hundreds of customers) as a BGP router and PPPoE server (the latter replacing MikroTik because of their unfinished IPv6 support), not big enough to be able to afford a subscription.

Sorry about the priority, but it may be quite serious for those who will lose access due to end of program "images for donations" on May 1, and would like to be able to build stable images from source.

Unfortunately not yet resolved for 1.4 - now reported separately here https://vyos.dev/T6264

Meanwhile, trying to build 1.4 fails for a different reason - Debian 12 (bookworm) is still where it was, but sagitta-packages.vyos.net gives a 403 error:

As a temporary workaround, I use the script below. For some reason /etc/rc.local no longer runs automatically on VyOS 1.3.2, so I run it manually after each reboot for now. Until it is run, Phicomm routers keep disconnecting due to failed IPV6CP negotiation incorrectly triggering complete PPPoE session termination. I have two PPPoE servers at different locations for redundancy, both rebooting at the same time is very unlikely, so I can live with it for now.

See also https://github.com/accel-ppp/accel-ppp/issues/57
Testing this patch, PPPoE session with the Phicomm router now stays up, the missing part after "else" is to remove IPv6 configuration from ppp interface (not sure how to do it properly).

diff
diff --git a/accel-pppd/ppp/ppp_ipv6cp.c b/accel-pppd/ppp/ppp_ipv6cp.c
index 1194b31..2bac31b 100644
--- a/accel-pppd/ppp/ppp_ipv6cp.c
+++ b/accel-pppd/ppp/ppp_ipv6cp.c
@@ -738,7 +738,10 @@ static void ipv6cp_recv(struct ppp_handler_t*h)
                        if (conf_ppp_verbose)
                                log_ppp_info2("recv [IPV6CP TermReq id=%x]\n", hdr->id);
                        ppp_fsm_recv_term_req(&ipv6cp->fsm);
-                       ap_session_terminate(&ipv6cp->ppp->ses, TERM_USER_REQUEST, 0);
+                       if (conf_ipv6 == IPV6_REQUIRE)
+                               ap_session_terminate(&ipv6cp->ppp->ses, TERM_USER_REQUEST, 0);
+                       else
+                               ppp_layer_passive(ipv6cp->ppp, &ipv6cp->ld);
                        break;
                case TERMACK:
                        if (conf_ppp_verbose)

Log messages - http://91.224.224.43/phicomm/phicomm6.log
PPPoE server config:

In T4456#125497, @Viacheslav wrote:

@marekm Did you set a proper listen to address for it?

set system ntp listen-address x.x.x.x

Just my thoughts - there are situations where rp_filter is not sufficient, and it was not clear to me how to do this cleanly with the zone firewall, so I ended up hacking a few iptables commands in rc.local instead.

In T2829#73944, @c-po wrote:

There can not be a config migrator, thus the setting will be changed to "prefer" (default) which will not break any client implementations

Even with customers routes redistributed by OSPF instead of iBGP, it has just crashed again:

I tried unit-cache earlier but it seems to have issues too - I've seen duplicate routes if the same client (all have static IP assigned by RADIUS based on username) connects to a different PPPoE server and the old route is not removed, as if the cached (not removed) PPPoE interfaces were not seen as removed in FRR. But I haven't investigated this in more detail as it's a production setup, can't experiment too much on live customers.
I'm considering if I could go back to redistributing PPPoE customers /32 routes in OSPF instead of iBGP - it has been that way for a few years (using MikroTik, before moving to VyOS), but I've recently changed it following "BGP Best Current Practices" http://www.bgp4all.com.au/pfs/_media/workshops/05-bgp-bcp.pdf which recommends using OSPF only for infrastructure, not customers - seems logical to me as BGP was designed for much larger routing tables (all of the Internet), but perhaps OSPF is still good enough for just a few hundreds of customers.

I've just had two different routers (one bare metal and one VM) crash roughly at the same time, triggered by many PPPoE sessions disconnecting at the same time due to a short power failure (routers itself had power all the time, but power was interrupted for about a minute to a switch on the network between the routers and PPPoE clients). Stack traces are very similar (absolute addresses differ, but the same functions and offsets in them). And again, each time watchfrr restarted bgpd but it was not working until reboot. No problems so far with two other BGP routers running a similar configu but without any dynamic interfaces (only OSPF and BGP, no PPPoE servers).

In T2820#74102, @Viacheslav wrote:

It crashed again after 5 days in 1.2.6-epa1, in the same function, also when a dynamic PPPoE interface was deleted.
It happens less frequently after the former customers who repeatedly failed authentication have been physically disconnected.
Again, BGP no longer works after watchfrr has restarted the bgpd process. All works again after reboot.

Maybe related - https://github.com/FRRouting/frr/issues/6439