@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:
In T2518#127884, @jack9603301 wrote:@ajgnet If you have a way to limit the dynamic prefix to a known prefix, then using 1:1 NAT66 prefix translation should work (only the host segment is dynamic)
Yes, would be great to fully support dynamic prefix when the prefix is not known
Will be fixed in https://github.com/vyos/vyos-1x/pull/1458
Aug 8 2022
ping-check shouldn't be allowed by default
To enable it you have to set set service dhcp-server shared-network-name Lan01 ping-check
There is no configuration in generated .conf:
vyos@r14# cat /run/dhcp-server/dhcpd.conf | grep ping [edit] vyos@r14#
See also https://github.com/accel-ppp/accel-ppp/issues/57
Testing this patch, PPPoE session with the Phicomm router now stays up, the missing part after "else" is to remove IPv6 configuration from ppp interface (not sure how to do it properly).
diff diff --git a/accel-pppd/ppp/ppp_ipv6cp.c b/accel-pppd/ppp/ppp_ipv6cp.c index 1194b31..2bac31b 100644 --- a/accel-pppd/ppp/ppp_ipv6cp.c +++ b/accel-pppd/ppp/ppp_ipv6cp.c @@ -738,7 +738,10 @@ static void ipv6cp_recv(struct ppp_handler_t*h) if (conf_ppp_verbose) log_ppp_info2("recv [IPV6CP TermReq id=%x]\n", hdr->id); ppp_fsm_recv_term_req(&ipv6cp->fsm); - ap_session_terminate(&ipv6cp->ppp->ses, TERM_USER_REQUEST, 0); + if (conf_ipv6 == IPV6_REQUIRE) + ap_session_terminate(&ipv6cp->ppp->ses, TERM_USER_REQUEST, 0); + else + ppp_layer_passive(ipv6cp->ppp, &ipv6cp->ld); break; case TERMACK: if (conf_ppp_verbose)
I have tested macsec with gcm-aes-256. It works. (1.4-rolling-202208080217)
I have tested on 1.4-rolling-202208080217.
The first problem was fixed.
The second problem is not fixed
Aug 7 2022
Log messages - http://91.224.224.43/phicomm/phicomm6.log
PPPoE server config:
Hello, This functionality for nat66 is described here:
https://phabricator.vyos.net/T4586
Aug 6 2022
hi, you can set this to a subtask of my task