Yes, would be great to fully support dynamic prefix when the prefix is not known
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Aug 9 2022
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
Aug 5 2022
PR checks if openconnect port is listened by another service https://github.com/vyos/vyos-1x/pull/1460
It is already present in 1.4
vyos@r14:~$ show conf com | match bgp set protocols bgp listen limit '1000' set protocols bgp listen range 192.0.2.0/24 peer-group 'FOO' set protocols bgp local-as '65001' set protocols bgp peer-group FOO remote-as '65001'
It appeared after this commit
It doesn't like this check https://github.com/vyos/vyos-1x/blob/2a10ffa4b5074be27458159fa94d6227d0e5c7f7/src/op_mode/openconnect-control.py#L63-L65
Check root user https://github.com/vyos/vyos-1x/blob/2a10ffa4b5074be27458159fa94d6227d0e5c7f7/python/vyos/util.py#L625-L626
Aug 4 2022
Would it be an option to instead just add new listen-interface and upstream-interface statements, same as for dhcp-relay6? Then keep interface completely unchanged to avoid breaking weird usages, but add some deprecation notice to the CLI.
Currently thinking on how to implement this.
One option could be:
@hensur You haven't dealt with this for a long time
PR https://github.com/vyos/vyos-1x/pull/1458
Formatted output
vyos@r14:~$ show vpn ipsec sa Connection State Uptime Bytes In/Out Packets In/Out Remote address Remote ID Proposal ------------------------- ------- -------- -------------- ---------------- ---------------- ----------- --------------------------------------- peer_2001-db8--2_tunnel_0 up 9m15s 0B/0B 0/0 2001:db8::2 2001:db8::2 AES_CBC_256/HMAC_SHA2_256_128/MODP_2048 peer_2001-db8--2_tunnel_0 up 24m9s 0B/0B 0/0 2001:db8::2 2001:db8::2 AES_CBC_256/HMAC_SHA2_256_128/MODP_2048 vyos@r14:~$
From the strongswan 5.9.6 changelog:
Actively initiating duplicate CHILD_SAs within the same IKE_SA is now largely prevented. This can happen if trap policies are installed and an IKE_SA with its CHILD_SAs is reestablished (e.g. with break-before-make reauthentication or dpd_action=restart). This does not prevent duplicates if they are initiated by the two peers concurrently.
Aug 3 2022
also it would be good if WLB function will control main routing table, that would help to avoid a lot of confusion with protocols static configuration& WLB function. Current documentation does not telling anything about how exactly protocols static 0.0.0.0/0 route must be set with WLB.
From what I had tested:
1)WLB creates additional routing tables and setting PBR rules
2)without protocols static route 0.0.0.0 with next-hops to every wlb GW local vyos traffic would not work(as would not work traffic to vyos)
It sounds like people prefer jool, and in my personal opinion, if there is a package that is still active up to now, like jool, then jool is probably better. But whatever it is, it's foreign to me
PR https://github.com/vyos/vyos-1x/pull/1457
set nat66 destination rule 10 destination address '2001:db8:1111::/64' set nat66 destination rule 10 inbound-interface 'eth1' set nat66 destination rule 10 source address '!2001:db8::6/127' set nat66 destination rule 10 translation address '2001:db8::444' set nat66 source rule 10 destination prefix '2001:db8::2/128' set nat66 source rule 10 outbound-interface 'eth1' set nat66 source rule 10 source prefix '2001:db8:1111::/64' set nat66 source rule 10 translation address 'masquerade' set nat66 source rule 20 destination prefix '!2001:db8::6/127' set nat66 source rule 20 outbound-interface 'eth1' set nat66 source rule 20 source prefix '2001:db8:1111::/64' set nat66 source rule 20 translation address 'masquerade'
Also I had tried to assign IP addresses directly to wan interfaces to test if it's somehow related to usage of vrrp combined with WLB- it does not work.
Aug 2 2022
PR https://github.com/vyos/vyos-1x/pull/1456
vyos@r14:~$ /usr/libexec/vyos/op_mode/container.py restart --name alp01 Container name "alp01" restarted! vyos@r14:~$ vyos@r14:~$ /usr/libexec/vyos/op_mode/container.py restart --name alp02 Error: no container with name or ID alp02 found: no such container vyos@r14:~$
Hi friends, I'm experiencing what appears to be the same bug. In my case, it's on a redirect on a vif subinterface on a bonding interface. So perhaps bug is not so much about PPPoE interfaces, so much as any interfaces that don't exist before the commit is done.
PR https://github.com/vyos/vyos-1x/pull/1455
curl -k --raw 'https://localhost/graphql' \ -H 'Content-Type: application/json' \ -d '{"query":" {\n ShowVrf (data: {key: \"foo\"}) {\n success\n errors\n data {\n result\n }\n}\n}\n"}'
Getting data:
{"data":{"ShowVrf":{"success":true,"errors":null,"data":{"result":[{"ifname":"foo","operstate":"UP","address":"26:f6:35:05:7e:0a","flags":["NOARP","MASTER","UP","LOWER_UP"]}]}}}}
Works as expected in a recent rolling (e.g. 1.4-rolling-202208021045)