VyOS 1.3 based on Debian 10 Buster
Details
Yesterday
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 Jan 2021, but is still called by 'vyatta_interface_rescan' 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:
Fri, Sep 22
Wed, Sep 13
Which VyOS 1.4-rolling will have the fixes made by FRRouting?
Tue, Sep 12
Tue, Sep 5
Mon, Sep 4
Thu, Aug 31
I assume backports will be used once VyOS 1.3.4 gets compiled?
Wed, Aug 30
This also affects latest rolling release as of 1.4-rolling-202308240020 which is available @vyos.io
Tue, Aug 29
Mon, Aug 28
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
Aug 27 2023
Aug 16 2023
Jul 31 2023
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.
Jul 29 2023
Jul 23 2023
Jul 13 2023
Jul 12 2023
Jul 11 2023
Jul 6 2023
Jul 5 2023
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.
Jul 2 2023
Jul 1 2023
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.
Jun 30 2023
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
Jun 23 2023
Yes that works, output successful (see command in bug report).
Could you try with this command to see if the curl output is successful.