PR https://github.com/vyos/vyos-1x/pull/1827
set service pppoe-server authentication mode 'noauth' set service pppoe-server client-ip-pool name foo gateway-address '192.0.2.1' set service pppoe-server client-ip-pool name foo subnet '192.0.2.0/24' set service pppoe-server interface eth1
Check
vyos@r14# cat /run/accel-pppd/pppoe.conf | grep "\[auth" -A 2 [auth] noauth=1
Thanks for clarification @b-
This isn’t specific to WANs at all, no! I am using it for a WAN, so some of my comments reflect that, but really this is just a generic hook for any DHCP interface.
@b- Im not sure 100% sure whats happening, as I am not a developer... I saw your code samples and PR in git...
@mas90 Will be present in the next rolling release.
Could you check when it will available? After 20230215
PR https://github.com/vyos/vyos-1x/pull/1825
set system option keyboard-layout uk
Excellent! I'll check it out and report back. Thank you!
@ammmze That PR is merged, so will be in the next rolling. Kindly let me know of any remaining or other issues you see. I'll add autocannon to my common tests; thanks again for that tip.
In T4971#142523, @fernandolcx wrote:service { + pppoe-server { + authentication { + mode radius + radius { + server 172.31.255.2 { + key 123456 + } + } + } + interface eth1 { + } + } }when I commit, throws me:
Traceback (most recent call last): File "/usr/libexec/vyos/conf_mode/service_pppoe-server.py", line 114, in <module> verify(c) File "/usr/libexec/vyos/conf_mode/service_pppoe-server.py", line 60, in verify verify_accel_ppp_base_service(pppoe) File "/usr/lib/python3/dist-packages/vyos/configverify.py", line 424, in verify_accel_ppp_base_service for _, v in config['client_ip_pool']['name'].items(): KeyError: 'client_ip_pool'
Some debugging, the authentication with user vyosunpriv
set protocols bgp address-family l2vpn-evpn vni 100070 route-target both 70:100070
Should return an error, as this is not implemented.
I was wrong. NOT 6 CHILSD_SAs on one tunnel.
6 IKE SAs on one configured tunnel.
I met 2 issues after the last commit.
My config:
Awesome, I am glad to hear the provided info was helpful! Thank you for the quick investigation and explanation.
Again, thanks for the detailed reproducer; that made investigation straightforward. This appears to be simply an 'async' issue for FastAPI, the underlying web framework for vyos-http-api. FastAPI is very good at managing red/blue issues automatically, but in this case we need to explicitly annotate the endpoint method with async: an explicit lock does not appear necessary, though I will need to confirm. I'll provide a PR shortly. Thanks again !
Thanks Keving: https://vyos.dev/T5009
Error still present in 1.4: https://vyos.dev/T5004
FYI When I was troubleshooting I used:
In Both version, restarting relay service solved the issue:
@ammmze Thanks for the detailed report; allow me to investigate.
https://github.com/FRRouting/frr/pull/12364
riw777 merged commit 91b6db4 into FRRouting:master Feb 14, 2023
You can either run both address-families through one tunnel
Is there any kind of ETA on this? It hasn't moved in a few months, and it is preventing me from being able to upgrade. I understand this probably isn't a huge priority, but an ETA would be nice.
Then lets close it
I have prepared a configuration example using one of the latest 1.4 images, where more features were introduced.
Scenario and requirements:
Don't see any issue with 1.3
vyos@r1:~$ monitor bandwidth-test initiate 192.168.122.14 ------------------------------------------------------------ Client connecting to 192.168.122.14, TCP port 5001 TCP window size: 85.0 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.122.11 port 58042 connected with 192.168.122.14 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 6.37 GBytes 5.47 Gbits/sec vyos@r1:~$ vyos@r1:~$ show version
Everything works on version 1.4
In T4774#142529, @c-po wrote:Please note the WireGuard crypto Key routing concept: https://www.wireguard.com/#cryptokey-routing
Keys should not be re-used
Please note the WireGuard crypto Key routing concept: https://www.wireguard.com/#cryptokey-routing
Everything just worked fine.
service {
+ pppoe-server {
+ authentication {
+ mode radius
+ radius {
+ server 172.31.255.2 {
+ key 123456
+ }
+ }
+ }
+ interface eth1 {
+ }
+ }
}Sorry about the trouble - fixed in next rolling release.
PR for 1.3 https://github.com/vyos/vyos-1x/pull/1813
PR for 1.3 https://github.com/vyos/vyos-1x/pull/1812
okay, so with https://vyos.dev/T4997 in place (tested via my custom build https://github.com/b-/vyos-build-action/releases/tag/v1.4-rolling_bri_add-dhcp-user-hooks ) and the following file in /config/scripts/dhcp-client/post-hooks.d/set-addrgroup
#!/bin/sh # # /config/scripts/dhcp-client/post-hooks.d/set-addrgroup
Reading more of the fancy internal scripting going on inside VyOS, there's already both a place to put this script (that would cause it to automatically be called by dhclient upon a new address), _and_ it sets a bunch of variables for us so I don't have to hac hac hac parse output that really isn't intended to be parsed. https://github.com/vyos/vyos-1x/tree/current/src/etc/dhcp/dhclient-exit-hooks.d
#!/bin/vbash
source /opt/vyatta/etc/functions/script-template
configure
WAN_IF_GROUP=wan
show firewall group interface ${WAN_IF_GROUP} | cut -c 2- | cut -d' ' -f2 > /tmp/WANS
WANS=$(</tmp/WANS)
getip(){
#ip -4 a show ${1} | grep -Po 'inet \K[0-9.]*'
run show interface ${1:0:3} $1 brief | tr -s ' ' | grep $1 | cut -d' ' -f2 | cut -d/ -f1 | grep -v ':'
# returns like 123.234.34.34
# grep -v : removes ipv6
}