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

PRs:
1.3 - https://github.com/vyos/vyos-1x/pull/1979
1.4 - https://github.com/vyos/vyos-1x/pull/1978

Hi, the reason why the modem does not show up is because usb0 interfaces do not match the prefix we use to distinguish between interfaces.

Tested successfully! Modem showed up as usb0 in ip link, but not in show interfaces.

Added requested config option to Kernel for 1.4

• https://github.com/vyos/vyos-build/commit/88be901bc103d1c47adbbc874d02e8ec5cde3397

PR: https://github.com/vyos/vyos-build/pull/343

PR with dependencies: https://github.com/vyos/vyos-build/pull/341

PR (for build): https://github.com/vyos/vyos-build/pull/340

PR: https://github.com/vyos/vyos-build/pull/339