Do you have users/passwords with specsymbols or not utf-8 or some ascii symbols?
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
Feed All Stories
All Stories
All Stories
Apr 26 2023
Apr 26 2023
hmmm very strange.... here is my configuration (IP addresses removed):
Could you provide l2tp configuration? show conf com | match l2tp
I cannot reproduce it
vyos@r14:~$ vyos@r14:~$ show l2tp-server sessions ifname | username | ip | ip6 | ip6-dp | calling-sid | rate-limit | state | uptime | rx-bytes | tx-bytes --------+----------+--------------+-----+--------+---------------+------------+--------+----------+----------+---------- l2tp0 | alice | 100.64.203.0 | | | 192.168.122.1 | | active | 00:00:10 | 246 B | 208 B vyos@r14:~$ vyos@r14:~$ vyos@r14:~$ show version Version: VyOS 1.4-rolling-202304261027 Release train: current
@Viacheslav It hangs for a while and then eventually the following output:
@joshua.hanley Could you provide the output of the next command?
sudo accel-cmd -p 2004 show sessions
joshua.hanley updated the task description for T5184: Unable to display L2TP sessions l2tp-server sessions.
SrividyaA changed the status of T5127: VPNv4/VPNv6 routes are not reinstalled following link flap from Open to Confirmed.
PR with dependencies: https://github.com/vyos/vyos-build/pull/341
GitHub <noreply@github.com> committed rVYOSONEX930f76cf88a4: Merge pull request #1971 from sever-sever/T5181 (authored by c-po).
Apr 25 2023
Apr 25 2023
PR (for build): https://github.com/vyos/vyos-build/pull/340
GitHub <noreply@github.com> committed rVYOSONEX28429f615e1e: Merge pull request #1970 from jestabro/xml-merge (authored by c-po).
zsdc changed the status of T5180: initramfs-tools ignores firmware from updates directory from Open to In progress.
Viacheslav added a comment to T5181: Wrong dependencies or priorities for zebra vni vrf interfaces and bgpd.
Incorrect modify modify_section: starting search for '^vrf protocols' until '^exit-vrf'
vyos@r14# delete vrf name red vni
[edit]
vyos@r14# commit
[ vrf name red vni 3000 ]
{'name': {'protocols': {'bgp': {'address_family': {'ipv4_unicast': {'redistribute': {'connected': {}}},
'l2vpn_evpn': {'advertise': {'ipv4': {'unicast': {}}}}},
'system_as': '65001'}},
'table': '3000'}}
load_configuration: Configuration loaded from FRR daemon zebra
load_configuration: loaded 0 !
load_configuration: loaded 1 frr version 8.5
load_configuration: loaded 2 frr defaults traditional
load_configuration: loaded 3 hostname debian
load_configuration: loaded 4 log syslog
load_configuration: loaded 5 log facility local7
load_configuration: loaded 6 hostname r14
load_configuration: loaded 7 service integrated-vtysh-config
load_configuration: loaded 8 !
load_configuration: loaded 9 vrf red
load_configuration: loaded 10 vni 3000
load_configuration: loaded 11 exit-vrf
load_configuration: loaded 12 !
load_configuration: loaded 13 end
modify_section: starting search for '^vrf protocols' until '^exit-vrf'Two cents from the fields. It will be nice to see vrf aware cg-nat solution, when subscribers from a number of "inside" vrfs NAT'ed into one outside vrf. Of course if that's possible.
Viacheslav updated the task description for T5181: Wrong dependencies or priorities for zebra vni vrf interfaces and bgpd.
Viacheslav renamed T5181: Wrong dependencies or priorities for zebra vni vrf interfaces and bgpd from Wrong dependencies or priorities for zebra vni vrf and bgpd to Wrong dependencies or priorities for zebra vni vrf interfaces and bgpd.
jestabro renamed T5178: Fix missed case in multi_to_list conversion from Fix misssed case in multi_to_list conversion to Fix missed case in multi_to_list conversion.
jestabro added a comment to T5179: multi nodes defined in XML are not properly represented as list in get_config_dict().
Test case above produces:
jestabro added a comment to T5179: multi nodes defined in XML are not properly represented as list in get_config_dict().
Merged T5178 into this one; cf. the description there for background of the issue.
jestabro changed the status of T5178: Fix missed case in multi_to_list conversion from Open to In progress.
Apr 24 2023
Apr 24 2023
jestabro edited projects for T5175: http-api: error in MultiPart parser for FastAPI version >= 0.91.0, added: VyOS 1.3 Equuleus (1.3.3); removed VyOS 1.3 Equuleus.
PR for equuleus:
https://github.com/vyos/vyos-1x/pull/1969
jestabro edited projects for T5176: http-api: update vyos-http-api-tools for FastAPI security vulnerability, added: VyOS 1.3 Equuleus (1.3.3); removed VyOS 1.3 Equuleus.
PR for equuleus:
https://github.com/vyos/vyos-http-api-tools/pull/5
GitHub <noreply@github.com> committed rVYOSONEX728aa02c80c2: Merge pull request #1968 from nagua/patch-1 (authored by dmbaturin).
jestabro changed the status of T5175: http-api: error in MultiPart parser for FastAPI version >= 0.91.0 from Unknown Status to Unknown Status.
jestabro closed T5175: http-api: error in MultiPart parser for FastAPI version >= 0.91.0 as Unknown Status.
jestabro closed T5176: http-api: update vyos-http-api-tools for FastAPI security vulnerability, a subtask of T5175: http-api: error in MultiPart parser for FastAPI version >= 0.91.0, as Unknown Status.
jestabro closed T5176: http-api: update vyos-http-api-tools for FastAPI security vulnerability as Unknown Status.
According to nft changelog, this feature is available in 1.0.7 in a much better way:
@Harliff Could you check it? Available in the latest rolling release
vyos@r14# set protocols failover route 192.0.2.55/32 next-hop 192.168.122.1 check policy Possible completions: all-available All targets must be alive any-available Any target must be alive (default)
Hi guys,
Cheeze_It changed the status of T5081: ISIS and OSPF syncronization with IGP-LDP sync from Open to Needs testing.
Apr 23 2023
Apr 23 2023
jestabro triaged T5176: http-api: update vyos-http-api-tools for FastAPI security vulnerability as High priority.
jestabro changed the status of T5175: http-api: error in MultiPart parser for FastAPI version >= 0.91.0 from Open to In progress.
jestabro added a comment to T5175: http-api: error in MultiPart parser for FastAPI version >= 0.91.0.
This has a simple fix: starlette commit c568b55d set the attribute
Request._form = None
to support use of Request.form() as a context manager. Since we override the Request class for backwards-compatibility support (translation) of form-data requests, we need to check for value, not existence, of the attribute. Adding this fix allows updating FastAPI past 0.91.0.
jestabro renamed T5175: http-api: error in MultiPart parser for FastAPI version >= 0.91.0 from http-api: error in MultiPart parser for FastAPI version >= 0.90.0 to http-api: error in MultiPart parser for FastAPI version >= 0.91.0.
jestabro renamed T5175: http-api: error in MultiPart parser for FastAPI version >= 0.91.0 from http-api: error in MultipPart parser for FastAPI version >= 0.90.0 to http-api: error in MultiPart parser for FastAPI version >= 0.90.0.
jestabro updated the task description for T5175: http-api: error in MultiPart parser for FastAPI version >= 0.91.0.
jestabro triaged T5175: http-api: error in MultiPart parser for FastAPI version >= 0.91.0 as Urgent! priority.
c-po changed the status of T5174: vrf: ensure no duplicate VNIs can be created from Open to In progress.
Apr 22 2023
Apr 22 2023
GitHub <noreply@github.com> committed rVYOSONEX6b81f048a0cd: Merge pull request #1966 from sever-sever/T1237 (authored by c-po).
GitHub <noreply@github.com> committed rVYOSONEXc90705801529: Merge pull request #1962 from indrajitr/ddclient-opmode-2 (authored by dmbaturin).
Apr 21 2023
Apr 21 2023
GitHub <noreply@github.com> committed rVYOSONEX66bc0d231aa1: Merge pull request #1957 from aapostoliuk/T5042-sagitta (authored by c-po).
GitHub <noreply@github.com> committed rVYOSONEX19c5040eaa09: Merge pull request #1965 from dmbaturin/python-dep (authored by c-po).
bfd is able to monitoring static routes , using profiles and multi-hop to reached a peer :
PR https://github.com/vyos/vyos-1x/pull/1966
set protocols failover route 192.0.2.55/32 next-hop 192.168.122.1 check policy 'any-available' set protocols failover route 192.0.2.55/32 next-hop 192.168.122.1 check target '192.168.122.1' set protocols failover route 192.0.2.55/32 next-hop 192.168.122.1 check target '192.168.122.11' set protocols failover route 192.0.2.55/32 next-hop 192.168.122.1 check timeout '3' set protocols failover route 192.0.2.55/32 next-hop 192.168.122.1 interface 'eth0'
Viacheslav added a comment to T5171: Use XML for conf-mode "load-balancing wan" instead of legacy templates.
Don't have any idea how to integrate this logic to XML https://github.com/vyos/vyatta-wanloadbalance/blob/973421035568810e2583187c48d14054970b9806/templates/load-balancing/wan/node.def#L2-L5
GitHub <noreply@github.com> committed rVYOSONEX821bc4f51146: Merge branch 'current' into current (authored by dmbaturin).
Zhiyuan Wan <h@iloli.bid> committed rVYOSONEXdcba3685345b: T5123: op-mode: Support to show detailed ospf route table.
GitHub <noreply@github.com> committed rVYOSONEX192c8ed2bcad: Merge pull request #1921 from rgwan/current (authored by dmbaturin).
Just in case someone wants to implement this: debugging must not be enabled by default, only on demand or via config.
Apr 20 2023
Apr 20 2023
Per VyOS maintainers, this operation isn't necessary.
Viacheslav renamed T5171: Use XML for conf-mode "load-balancing wan" instead of legacy templates from Use XML for conf-mode "load-balancing wan" instead of legasy templates to Use XML for conf-mode "load-balancing wan" instead of legacy templates.
Viacheslav renamed T5171: Use XML for conf-mode "load-balancing wan" instead of legacy templates from Use XML for conf-mode "load-balancing wan" instead of templates to Use XML for conf-mode "load-balancing wan" instead of legasy templates.
Viacheslav changed the status of T5171: Use XML for conf-mode "load-balancing wan" instead of legacy templates, a subtask of T4470: Rewrite load-balancing wan to XML/Python, from Open to In progress.