@jack9603301 follow forum topic, all data randomized.
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
Feed Search
Jan 25 2021
Jan 25 2021
Unknown Object (User) changed the status of T3251: PPPoE client trying to authorize with the wrong username from Open to In progress.
Unknown Object (User) added a comment to T3251: PPPoE client trying to authorize with the wrong username.
For security, don't expose your user name and password
Unknown Object (User) created T3251: PPPoE client trying to authorize with the wrong username.
Unknown Object (User) created T3250: PPPoE server: wrong local usernames.
jack9603301 changed the subtype of T3249: Support operation mode forwarding table output from "Task" to "Feature Request".
jack9603301 moved T3249: Support operation mode forwarding table output from Need Triage to In Progress on the VyOS 1.3 Equuleus board.
Jan 24 2021
Jan 24 2021
c-po renamed T3248: Deal with VRRP mode-force command that exists in 1.2 but not in 1.3 from Deal with VRRP mode-force command that exists in 1.3 but not in 1.3 to Deal with VRRP mode-force command that exists in 1.2 but not in 1.3.
dmbaturin moved T1773: Make it possible to export config to JSON from Needs Triage to Finished on the VyOS 1.2 Crux (VyOS 1.2.7) board.
dmbaturin removed a project from T1350: VRRP transition script will be executed once only: VyOS 1.2 Crux (VyOS 1.2.7).
In light of the mode-force in 1.2.x, we definitely can't make this the new default within an LTS branch.
dmbaturin moved T1774: Add a show config operation to the HTTP API from Needs Triage to Finished on the VyOS 1.2 Crux (VyOS 1.2.7) board.
dmbaturin moved T1957: PPPoE server: maintenance mode from Needs Triage to Finished on the VyOS 1.2 Crux (VyOS 1.2.7) board.
dmbaturin moved T3246: OSPFv3 router ID not configured in FRR from Needs Triage to Finished on the VyOS 1.2 Crux (VyOS 1.2.7) board.
show tech-support
Viacheslav changed the status of T3246: OSPFv3 router ID not configured in FRR from Open to Needs testing.
c-po moved T3194: OSPF redistribution metric issue from Needs Triage to Finished on the VyOS 1.2 Crux (VyOS 1.2.7) board.
c-po moved T3194: OSPF redistribution metric issue from Need Triage to Finished on the VyOS 1.3 Equuleus board.
Or the configuration is simply passed to the wrong daemon
The old scheme generate
PR https://github.com/vyos/vyatta-cfg-quagga/pull/65
Delete old Perl handler "vyatta-bgp.pl" for bgp.
c-po closed T3227: Latest releases don't work with RPKI (crash), a subtask of T2174: Rewrite protocol BGP to new XML/Python style, as Resolved.
This bug got fixed with: https://phabricator.vyos.net/T3227
jack9603301 changed the status of T2518: Add support for IPv6 NAT (NPTv6) from In progress to Needs testing.
jack9603301 moved T2518: Add support for IPv6 NAT (NPTv6) from In Progress to Finished on the VyOS 1.3 Equuleus board.
Jan 23 2021
Jan 23 2021
Unknown Object (User) created T3242: PPPoE Server overhead on virtual interfaces creation.
Created the feature request on forum.
sempervictus added a comment to T2884: Upstream Kernel Patches from Semper Victus Linux Hardened Tree.
I've been refreshing the stack against current branch to keep testers building, and have added the FSGSBASE backport to 5.4 as a technical argument for keeping to a properly mature LTS even when users have a good case for needing newer functionality.
What is the plan of action for this effort, and is there a written policy on which kernels are selected and how they're selected for the OS? I can keep doing the rebase & push dance once a week or so, but is anyone on the VyOS team actually testing this stuff and has anyone upstream discussed the functional security benefits to users of GeoIP firewall filters or TARPIT/DELUDE/etc response actions separately from the system hardening functions inhere?
c-po changed the status of T2638: FRR: New framework for configuring FRR from Open to Needs testing.
c-po changed the status of T2174: Rewrite protocol BGP to new XML/Python style from Open to Needs testing.
c-po changed the status of T3227: Latest releases don't work with RPKI (crash), a subtask of T2174: Rewrite protocol BGP to new XML/Python style, from Confirmed to Needs testing.
Jan 22 2021
Jan 22 2021
After solving this requirement of vyos and confirming its normal operation, it is recommended to provide a feedback repair patch and submit a pr
WOW! Any chance getting this upstreamed? That would be the overall best solution - I still like it and think we should add it, but fetching the source from upstream reduces our maintenance load.
Do you have a plan to backport it to 1.2?
See T3240 for a proper fix.
jestabro changed the status of T3239: XML: override 'defaultValue' for mtu of certain interfaces; remove workarounds, a subtask of T2910: XML: generator should support override of variables, from Resolved to Unknown Status.
jestabro changed the status of T2910: XML: generator should support override of variables from Resolved to Unknown Status.
Jan 21 2021
Jan 21 2021
c-po changed the status of T1875: Add the ability to use network address as BGP neighbor (bgp listen range), a subtask of T2174: Rewrite protocol BGP to new XML/Python style, from Open to Needs testing.
c-po changed the status of T1875: Add the ability to use network address as BGP neighbor (bgp listen range) from Open to Needs testing.
c-po moved T3237: DHCP Server Static-Mapping Validation Error from Need Triage to Finished on the VyOS 1.3 Equuleus board.
c-po moved T3237: DHCP Server Static-Mapping Validation Error from Needs Triage to Finished on the VyOS 1.2 Crux (VyOS 1.2.7) board.
vyos@vyos# set service dhcp-server shared-network-name LAN subnet 10.242.0.0/24 static-mapping AlexPC mac-address 00-d8-61-9e-78-2a
c-po added a project to T3237: DHCP Server Static-Mapping Validation Error: VyOS 1.2 Crux (VyOS 1.2.7).
The problem is that there is no input validator for the mac address. Thank you for reporting this!
c-po changed the status of T3237: DHCP Server Static-Mapping Validation Error from Open to In progress.
Will remove test case and rebase to create PR and merge for 1.4; will later backport to 1.3 pending any issue.
I have finished the test of nat66 in GNS lab
Jan 20 2021
Jan 20 2021
Two minor comments left out of the above:
(1) The script in question runs a check on all interface definitions, however, there is no measurable increase in compile time.
(2) lxml will escape characters '>', '<', however these are unescaped by build-command-templates, so the issue is mooted. One can see the single line changed in the XML by running the test case above; it is noted that some interface definitions already have a mixed use of, say, '>' and '>'.
Feature was present in 1.2 and until now not possible with nftables, so we keep the old CLI and just replace the engine for now. Adding the prefix option simply feels more complicated in terms of validation logic and scripting.
Since the current branch uses the kernel Linux 5.10+, I began to pay attention to the implementation of NPT again. At present, I have completed the following features:
'nopmtudisc' option still not present
@c-po Why not consider dnat prefix to? Maybe it's more convenient
Jan 19 2021
Jan 19 2021
jestabro changed the status of T2910: XML: generator should support override of variables from Open to Needs testing.
Preprocessing solution in testing here:
https://github.com/vyos/vyos-1x/compare/current...jestabro:override-default
Implemented on the 1.4 current branch, once the QAT issues are resolved for 5.10 Linux Kernel this can be backported after successful testing to 1.3 equuleus LTS branch.
c-po changed the status of T2947: Nat translation many-many with prefix does not map 1-1., a subtask of T3092: nat: migrate to get_config_dict(), from Confirmed to Needs testing.
c-po changed the status of T2947: Nat translation many-many with prefix does not map 1-1. from Confirmed to Needs testing.
c-po added a project to T2947: Nat translation many-many with prefix does not map 1-1.: VyOS 1.4 Sagitta.
Looks good. But maybe it is reasonable to change argument start-suppress-time to start-suppress because it is not a time, but penalty points
Viacheslav changed the status of T2629: VXLAN interfaces don't actually allow you to configure most settings from Open to Needs testing.
Jan 18 2021
Jan 18 2021
Interesting. I agree, I think that defeats the purpose of VRRP if both have to be running. I guess we can go ahead and close this as not feasible at this time.
"the VRRP instance will only be able to come up if both VRRP instance are running, which somewhat defeats the purpose of VRRP. " ref https://manpages.debian.org/buster/keepalived/keepalived.conf.5.en.html
Fixed, VyOS 1.4-rolling-202101171022
vyos@r5-roll:~$ show vrrp Name Interface VRID State Priority Last Transition ------ ----------- ------ ------- ---------- ----------------- GRP eth1 99 MASTER 90