@florin Do you plan to make a pull request?
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Aug 14 2022
Great, thanks
It seems after this commit https://github.com/vyos/vyos-1x/commit/08cb762347208b21a8cbf81f7b35707d7e6dd4ac
I’ll take a look later
Aug 13 2022
Using the pull requests filesystem copy, same place, new error:
vyos@vyos-515:~$ cat /var/log/vyatta/*log cp[/opt/vyatta/config/tmp/new_config_1615]->[/opt/vyatta/config/tmp/tmp_1615/work] cp w->tw failed[unknown exception] cp[/opt/vyatta/config/tmp/new_config_2665]->[/opt/vyatta/config/tmp/tmp_2665/work] cp w->tw failed[unknown exception] vyos@vyos-515:~$ dpkg -l|grep vyatta-cfg ii libvyatta-cfg-dev 0.102.0+vyos2+current5 amd64 libvyatta-cfg development package ii libvyatta-cfg1 0.102.0+vyos2+current5 amd64 vyatta-cfg back-end library ii libvyatta-cfg1-dbgsym 0.102.0+vyos2+current5 amd64 debug symbols for libvyatta-cfg1 ii vyatta-cfg 0.102.0+vyos2+current5 amd64 VyOS configuration system ii vyatta-cfg-dbgsym 0.102.0+vyos2+current5 amd64 debug symbols for vyatta-cfg ii vyatta-cfg-qos 0.15.42+vyos2+current1 all VyOS Qos configuration templates/scripts ii vyatta-cfg-system 0.20.44+vyos2+current22 amd64 VyOS system-level configuration vyos@vyos-515:~$ uname -r 5.15.59-amd64-vyos-sv vyos@vyos-515:~$
If Linux maintainers backport the delta causing this to 5.10, it could become a rather pressing concern, but for now merely a show-stopper in terms of moving past 5.10LTS.
Created a pull request implementing a rudimentary fall-through-on-exception to standard API from the Boost version @ https://github.com/vyos/vyatta-cfg/pull/49
Have not built it yet, nor am i a formal C++ developer (hackers are informal everything developers and rarely formal anything developers), so would appreciate eyes on and sanity checks.
Exception can probably be scoped better to only trip on EXEDEV but i dont see a logical problem with falling-through like this on other errors (is this a bad assumption?).
PR https://github.com/vyos/vyos-1x/pull/1466
Let me know if there is what you are expecting,
requires more tests
set nat static rule 10 destination address '10.0.1.1' set nat static rule 10 inbound-interface 'eth0' set nat static rule 10 translation address '192.168.1.1'
Aug 12 2022
@artooro Did you try listen-port option for this case?
set service https api gql set service https api keys id KID key 'foo' set service https api socket set service https virtual-host foo listen-port '2580'
Check:
vyos@r14# sudo netstat -tulpn | grep nginx tcp 0 0 0.0.0.0:2580 0.0.0.0:* LISTEN 3570/nginx: master tcp6 0 0 :::2580 :::* LISTEN 3570/nginx: master [edit] vyos@r14#
@n.fort Create please PR for 1.3
Aug 11 2022
@aserkin Will be present in the next rolling release.
@ajgnet Could you show routes after this bug?
sudo ip -6 route show sudo ip -6 route get 2607:f8b0:4006:80d::200e
Aug 10 2022
I've verified this behavior with 1.4-rolling-202207290217 and 1.4-rolling-202204250217.
Hi Viacheslav
Sorry, i probably misspelled the config option. Actually it's availabe at [radius] section of accel-ppp.conf.
Below is the [radius] section from my /run/accel-pppd/l2tp.conf after i changed
/usr/libexec/vyos/conf_mode/vpn_l2tp.py:
What version you are using?
@aserkin Could you send an example of the required accel-ppp section? And how do you see this command in VyOS CLI?
Aug 9 2022
Allow me to proof the opposite.
As remarked and as expected, this option is not enable by default.
Proofs:
- Fist scenario: no ping-check option introduced in configuration: