I'd go with option 1 to have a well known list of working and supported LCD displays. Each will have it's own configuration template which is used when implementing. I'm not a fan of "power user options" as this usually causes more harm then good - also users tend to be overwhelmed by the number of CLI options. We rather should make adding new display types super easy with proper documentation.
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
Feed Search
Jun 19 2020
Jun 19 2020
Jun 18 2020
Jun 18 2020
Works as expected!
c-po changed the status of T2556: "show interfaces vrrp" does not return any interface from Open to Confirmed.
This does not work in VyOS 1.2.5 either.
c-po reopened T2588: Add support for default values to the interface-definition format as "In progress".
Jun 17 2020
Jun 17 2020
Perfect. Thank You! I was against this feature the first time bit now I need it, too ;)
The boot config load mechanism has been changed by @jestabro which possibly led to resolution of this bug
@Dmitry I accidently merged this to quick. Now every RADIUS instance has a peiority node bit irs only evaluates foe system login. Can dou please fix the XML definitions to only have this for system login?
c-po changed the status of T2609: router-advert: radvd does not start when lifetime is improperly configured from Open to In progress.
c-po changed the status of T2478: login radius: use NAS-IP-Address if defined source address from Unknown Status to Resolved.
c-po moved T2478: login radius: use NAS-IP-Address if defined source address from Needs Triage to Finished on the VyOS 1.2 Crux (VyOS 1.2.6) board.
c-po edited projects for T2478: login radius: use NAS-IP-Address if defined source address, added: VyOS 1.2 Crux (VyOS 1.2.6); removed Ready for Crux (1.2.x).
c-po moved T2478: login radius: use NAS-IP-Address if defined source address from Need Triage to Finished on the VyOS 1.3 Equuleus board.
Feature now also in crux version ob libpam-radius.
Jun 16 2020
Jun 16 2020
c-po moved T2605: SNMP service is not disabled by default from Need Triage to Finished on the VyOS 1.3 Equuleus board.
c-po moved T2605: SNMP service is not disabled by default from Needs Triage to Finished on the VyOS 1.2 Crux (VyOS 1.2.6) board.
Jun 15 2020
Jun 15 2020
My fault. defaultValue must pe placed outside of properties
@alexandrestein can I assume you‘re using NPTv6 on VyOS 1.2 series? If so you mind sharing an example/configuration so we can also improve our documentation?
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface IP Address S/L Description
--------- ---------- --- -----------
dum0 172.18.254.201/32 u/u
eth0 - u/u
eth0.5 - u/u
eth0.10 - u/u
eth0.15 - u/u
eth0.201 172.18.201.10/24 u/u
eth0.202 2001:affe::201/64 u/u
eth1 fd00::ffff/64 u/u
eth2 - A/D
lo 127.0.0.1/8 u/u
::1/128vyos@vyos:~$ show config commands | grep traffic set interfaces pppoe pppoe0 traffic-policy out 'QoS' set traffic-policy shaper QoS bandwidth '50mbit' set traffic-policy shaper QoS default bandwidth '100%' set traffic-policy shaper QoS default queue-type 'fq-codel' vyos@vyos:~$ tc class show dev pppoe0 vyos@vyos:~$
c-po moved T2599: "show interfaces" does not list VIF interfaces in ascending order from Need Triage to Backlog on the VyOS 1.3 Equuleus board.
c-po moved T2576: "show interfaces" does not return VTI from Need Triage to In Progress on the VyOS 1.3 Equuleus board.
c-po changed the status of T2600: RADIUS system login configuration rendered wrongly from Open to In progress.
c-po renamed T2599: "show interfaces" does not list VIF interfaces in ascending order from "show interfaces" does not list VIF interfaces in natural sorted order to "show interfaces" does not list VIF interfaces in ascending order.
Please also share your NAT configuration
Jun 14 2020
Jun 14 2020
Probably is can be set in a curlrc file which is populated from CLI options
c-po added a project to T1538: Update conntrack-sync packages to fix VRRP issues: VyOS 1.3 Equuleus.
Booting on VMware ESX with EFI works as expected.
Is this still an issue? Or does it now work in EFI systems?
c-po closed T2354: Wireless conf_mode errors, a subtask of T2353: Interface [conf_mode] errors parent task, as Resolved.
c-po closed T2594: Missing firmware for iwlwifi, a subtask of T1958: Include only firmware we actually need, as Resolved.
c-po placed T1070: SWANCTL: DMVPN: ALL peers are deleted in swan when opennhrp tries to delete ONE peer up for grabs.
Jun 14 2020, 3:36 PM · Bugs, VyOS 1.3 Equuleus (1.3.9), VyOS 1.4 Sagitta (1.4.0-GA), Restricted Project
Okay, root cause is the extraction script which parses the Kernel source for included source/object files.
@jjakob by a weird coincidence I yesterday received a Thinkpad T420s which shows the exact same error.
In T2594#67314, @jack9603301 wrote:For driver firmware, it's just a ko file, which can then be used by setting the boot in the configuration directory to automatically load the kernel file, or by using the following command:
depmod modprobe mykoConsidering the general Linux, the path of this driver and kernel component is usually:
/lib/modules/`uname -r`/kernel/driver/mymod/
Okay, the file is correctly installed, the question is, why the firmware is not accepted by the card. So there is no bug in general of the build system.
@jjakob installing all firmware files will again bload the image. As said - root cause must be determined why that particular file did not end up in the image. The repo holds the firmware in question (https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/iwlwifi-3945-2.ucode) so I'm currently debugging why it's not shipped.
Any rolling ISO generated after vyos-1.3-rolling-202006140117-amd64.iso will have the fix.
c-po added a comment to T2593: source NAT translation port can not be set when translation address is set to masquerade.
Any rolling ISO generated after vyos-1.3-rolling-202006140117-amd64.iso will have the fix.
c-po added a comment to T2593: source NAT translation port can not be set when translation address is set to masquerade.
It now renders to:
c-po added a comment to T2593: source NAT translation port can not be set when translation address is set to masquerade.
The mentioned configuration results into this snippet on VyOS 1.2.5
c-po changed the status of T2593: source NAT translation port can not be set when translation address is set to masquerade from Open to In progress.
It is not recommended to install Debian firmware- packages over vyos-linux-firmware. The question is why the firmware file in question is not pulled in automatically.
T2569 did an entire rewrite of the console command in XML / Pyhton. Bugfix for this problem is also tracked in that task.
Jun 13 2020
Jun 13 2020
c-po closed T2321: VRF support for SSH, NTP, SNMP service, a subtask of T2579: The root task for VRF features, as Resolved.
c-po changed the status of T2321: VRF support for SSH, NTP, SNMP service, a subtask of T2579: The root task for VRF features, from Open to Needs testing.
c-po changed the status of T2321: VRF support for SSH, NTP, SNMP service from Open to Needs testing.
vyos@vyos:~$ show vrf black processes 4624 sshd 4404 ntpd
@daniil it will be fixed in tomorrows rolling ISO.
Can you share what you did to make it work again? NAT has recently be rewritten which could be the root cause.
Jun 12 2020
Jun 12 2020
A config Syntax is always migratable. Wide also supports scripts, but ISC PD (as I‘ve seen it, and interpret it) seems to have some rough edges. If you find a guide I will definately have a look.
@jjakob it was only choosen as it prooved to be "more simple" compared to ISC and that helper script. I have no affiliation with either implementation. I was not aware that it could cause other issue. If you need to change it to ISC you're free to go.
Jun 11 2020
Jun 11 2020
Unfortunately this results in an error: