I had the below set on the pppoe interface to allow for DHCPv6-PD. That part was working fine it was just the pppoe interface that wasn't picking up an address:

Did you try it?

set interfaces pppoe pppoe1 ipv6

PR for 1.5: https://github.com/vyos/vyatta-cfg-system/pull/213

This functionality has also been backported to 1.4 so it will be in the next LTS release.

@fsbof This change was accepted so it should end up in the 1.5 rolling soon. I suspect backporting to 1.4 wouldn't be an issue but that is a question for a more senior dev. But as for 1.3, I am unsure as I have never ran that version and don't know if there are any changes between those releases that would make it a pain to backport.

@JeffWDH I am happy to download, build and test when you're ready if you point me to the right version(s)/location(s). I'm also very new to this but I managed to Build Equuleus in a docker container which has been working ok. Appreciate your efforts.

I've updated this to default to no ASCII art as I think it's cleaner, but added an option to show it if you want to see it:

Wow - you guys work quickly! 👍

I think it should be included, its often used during generation in Debian among other distros.

I wonder if we need the ASCII art though or not the plain fingerprints only (first line of the command)

This is an artifact of the remaining use in 1.3 of the legacy XorpConfigParser: the last use of that legacy piece was removed from 1.4 in Sep 2021, but is still called by 'vyatta_interface_rescan' in 1.3, so will be seen after changing MAC addresses if the config is not saved. A quick summary of the history is here and quoted below:

Which VyOS 1.4-rolling will have the fixes made by FRRouting?

I assume backports will be used once VyOS 1.3.4 gets compiled?

This also affects latest rolling release as of 1.4-rolling-202308240020 which is available @vyos.io

Fixed in https://github.com/FRRouting/frr/pull/14290

Same issue. So building Equuleus isn't possible at all anymore? I don't quite understand that the message is "it will be fixed eventually" but at the same time it's tagged as "Wont fix".

it will be fixed eventually

The same bug was with ipoe-server https://vyos.dev/T5283
It is the actual address x.x.x.0 for UNIX devices and PPP interfaces, but it could be issue work Windows clients
There is a simple fix https://github.com/vyos/vyos-1x/commit/8a79769bf447cb18d456f061afd6a7997b8264f8

I'm sorry.
I tested this is VyOS 1.3.3.
I tested mutliple configurations, from subnet /23 all the way up to /32 with the command "set service pppoe-server client-ip-pool subnet <x.x.x.x/x>"
After setting the subnet i'd connect multiple clients to VyOS and check wether all the available IP addresses were used, and they were.

Which version?
Which tested config? Which generated config?
It would be more clear if you provided tangible examples.

In talking with the vendor, this appears to be an incompatibility with the WiFi card and the coreboot BIOS installed on the device. Tested with a second device that had a different card installed, and no such errors are present now.

VyOS 1.4-rolling-202306280317 show the following additional dmesg items

Tried the following:

echo 1 > /sys/bus/pci/devices/0000:03:00.0/remove
echo 1 > /sys/bus/pci/rescan

Attempted a modprobe -r ath10k_pci and the re-load the module. The following dmesg is what I saw after.

https://github.com/vyos/vyos-1x/pull/2063

That fixes it. It does seem like more of a band-aid solution though. I don't want to have to do that for every router I deploy using this setup

Wireguard is not yet exists in the system when tun is already exists due to priority

vyos@r14:~$ /opt/vyatta/sbin/priority.pl | match "tun|wireguard"
380 interfaces/tunnel
381 interfaces/wireguard

Yes that works, output successful (see command in bug report).

Could you try with this command to see if the curl output is successful.

… I am fairly new to VyOS and the process so please apologize my basic question. Just wanting to clarify if I did anything wrong with the bug report, or this just takes time or it won’t be fixed at all?

https://github.com/vyos/vyos-build/pull/359

All of the modem specific settings appear to be done through the web GUI of the modem.

Rule used for udev testing:

I successfully tested a udev rule to rename to wwan0.

Could you write and test an udev rule which renames the RNDIS usb0 device to wwan*?

PR with the fix: https://github.com/vyos/vyos-build/pull/350