Hello!
Please also add "single-session" to
set service pppoe-server ppp-options

xe-daemon.service is missing, please add it

@dmbaturin :
The keyboard bug is still there in VyOS-1.2.0-epa2! No keyboard possible in hyper-v virtual machine connection (console)

:-)

it works in rolling, it's just @dmbaturin who messed up RC builds

@syncer is it really finished for you? The bug is still there in my tests

In 1.2.0-rc10 the keyboard bug is still there as in RC9. No keyboard in hyper-v virtual machine connection. Latest rolling is ok (vyos-1.2.0-rolling+201812050337)

https://support.vyos.io/en/guides/building-gce-image/creating-an-instance-on-google-cloud

Hi @andersonpcazm,
I'd suggest to open a ticket with mikrotik in that case (https://mikrotik.com/support).
The source code fro accel in the version we use in the OS can be found here: https://github.com/vyos/vyos-accel-ppp.
Feel free to contact me any time if you or mikrotek support need further details, but so far, as you found out as well, your client side (the mikrotek device) has a faulty pppoe implementation or is just misconfigured.

problem exists when the client side is a mikrotik, when is a tp-link router, run fine

I just made a few first tests with VyOS 1.2.0-rolling+201811281529 and VyOS 1.2.0-RC9 (downloaded now) on Hyper-V 2012R2 (Generation 2 VM, SecureBoot off):

fixed and available in the next rolling release or via http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyatta-webproxy/vyatta-webproxy_0.2.110+vyos2+current2_all.deb.

Nov 28 20:09:18 rc9 accel-pppoe: eth1: recv [PPPoE PADI 08:00:27:fa:3e:50 => ff:ff:ff:ff:ff:ff sid=0000 <Service-Name > <Host-Uniq 390c0000>]
Nov 28 20:09:18 rc9 accel-pppoe: eth1: send [PPPoE PADO 08:00:27:c8:4a:32 => 08:00:27:fa:3e:50 sid=0000 <AC-Name vyos-ac> <Service-Name > <AC-Cookie ca898c164463d5ae46b694ff9e09c27d61efcc897802c91b> <Host-Uniq 390c0000>]
Nov 28 20:09:18 rc9 accel-pppoe: eth1: recv [PPPoE PADR 08:00:27:fa:3e:50 => 08:00:27:c8:4a:32 sid=0000 <Service-Name > <Host-Uniq 390c0000> <AC-Cookie ca898c164463d5ae46b694ff9e09c27d61efcc897802c91b>]
Nov 28 20:09:18 rc9 accel-pppoe: eth1: send [PPPoE PADS 08:00:27:c8:4a:32 => 08:00:27:fa:3e:50 sid=0001 <AC-Name vyos-ac> <Service-Name > <Host-Uniq 390c0000>]
Nov 28 20:09:18 rc9 accel-pppoe: eth1:: send [LCP ConfReq id=1 <auth PAP> <mru 1492> <magic 6b8b4567>]
Nov 28 20:09:18 rc9 accel-pppoe: eth1:: recv [LCP ConfReq id=1 <mru 1492> <magic 5624ae46>]
Nov 28 20:09:18 rc9 accel-pppoe: eth1:: send [LCP ConfAck id=1 ]
Nov 28 20:09:21 rc9 accel-pppoe: eth1:: send [LCP ConfReq id=1 <auth PAP> <mru 1492> <magic 6b8b4567>]
Nov 28 20:09:21 rc9 accel-pppoe: eth1:: recv [LCP ConfAck id=1 <auth PAP> <mru 1492> <magic 6b8b4567>]
Nov 28 20:09:21 rc9 accel-pppoe: eth1:: recv [PAP AuthReq id=1]
Nov 28 20:09:21 rc9 accel-pppoe: ppp0:test: connect: ppp0 <--> pppoe(08:00:27:fa:3e:50)
Nov 28 20:09:21 rc9 accel-pppoe: ppp0:test: send [PAP AuthAck id=1 "Authentication succeeded"]
Nov 28 20:09:21 rc9 accel-pppoe: ppp0:test: send [CCP ConfReq id=1 <mppe +H -M +S -L -D -C>]
Nov 28 20:09:21 rc9 accel-pppoe: ppp0:test: test: authentication succeeded
Nov 28 20:09:21 rc9 accel-pppoe: ppp0:test: recv [IPCP ConfReq id=1 <addr 0.0.0.0> <dns1 0.0.0.0> <dns2 0.0.0.0>]
Nov 28 20:09:21 rc9 accel-pppoe: ppp0:test: send [IPCP ConfReq id=1 <addr 179.109.80.55>]
Nov 28 20:09:21 rc9 accel-pppoe: ppp0:test: send [IPCP ConfNak id=1 <addr 100.64.0.1> <dns1 179.109.80.19> <dns2 179.109.80.20>]
Nov 28 20:09:21 rc9 accel-pppoe: ppp0:test: recv [CCP ConfReq id=1]
Nov 28 20:09:21 rc9 accel-pppoe: ppp0:test: send [CCP ConfAck id=1]
Nov 28 20:09:21 rc9 accel-pppoe: ppp0:test: recv [CCP ConfRej id=1]
Nov 28 20:09:21 rc9 accel-pppoe: ppp0:test: send [CCP ConfReq id=2]
Nov 28 20:09:21 rc9 accel-pppoe: ppp0:test: recv [IPCP ConfAck id=1 <addr 179.109.80.55>]
Nov 28 20:09:21 rc9 accel-pppoe: ppp0:test: recv [IPCP ConfReq id=2 <addr 100.64.0.1> <dns1 179.109.80.19> <dns2 179.109.80.20>]
Nov 28 20:09:21 rc9 accel-pppoe: ppp0:test: send [IPCP TermAck id=2]
Nov 28 20:09:21 rc9 accel-pppoe: ppp0:test: recv [CCP ConfAck id=2]
Nov 28 20:09:24 rc9 accel-pppoe: ppp0:test: recv [IPCP ConfReq id=2 <addr 100.64.0.1> <dns1 179.109.80.19> <dns2 179.109.80.20>]
Nov 28 20:09:24 rc9 accel-pppoe: ppp0:test: send [IPCP ConfAck id=2]

vyos@vyos# show service pppoe-server
authentication {

local-users {
    username treinamento01 {
        password 650598
        static-ip 100.64.0.1
    }
}
mode local

}
client-ip-pool {

start 100.64.0.1
stop 100.64.0.254

}
dns-servers {

server-1 179.109.80.19
server-2 179.109.80.20

}
interface eth1
limits {
}
local-ip 179.109.80.55
mtu 1480
ppp-options {

min-mtu 1480
mru 1480

}

my client, disconnects continuously,
i don't need IPC6 at moment, it's only a test
do i need more configuration to do pppoe-server function?
tested with local authentication and radius
sorry for the inconvenience, i'm new to Vyos, and i want to help improve it.

Tested functionality, no issues found:

Your client (00:0c:42:bd:02:05) disconnects.
PADT = Active Discovery Termination
Nov 27 18:16:43 vyos accel-pppoe: eth1: recv [PPPoE PADT 00:0c:42:bd:02:05 => 68:05:ca:01:6d:9d sid=1f80]

Creating /var/log/squid (sudo mkdir /var/log/squid) allows the commit to complete.

@MrXermon were you able to workaround the next hop issue you describe here as I am getting the same result from my peers?

This seems to be easy.
sudo chmod 776 /opt/vyatta/etc/config/archive/config.boot

Upgrade from 1.1.7 with a couple of changes in the rollback list to the current 1.2.0-rc9 also shows thi same error:
Couldn't open /opt/vyatta/etc/config/archive/config.boot - Permission denied at /opt/vyatta/share/perl5/Vyatta/ConfigMgmt.pm line 108.

@syncer In the 1.2.0-rc9 image this seems to be fixed. I upgraded to this release and the config is working flawlessly as far as i can tell now.
BGPD is started at boot, and no config parts are missing.
I am also running several BGP neighbors, and several of them with a full BGP table.

It seems that local auth is impossible, all I found is to configure it against radius, user should check abills as billing system. (https://sourceforge.net/projects/abills/)
If anyone knows how to use local authentication like chap or pap or anything, let me know please. Otherwise IPoE seems a real nice option, not as robust as ppp, but quite nice.

In T1001#26863, @arne wrote:

Is there any need to have backslashes in descriptions? Or, more generally: Is there any need to have non-ASCII characters in descriptions?

I am asking because we could either handle this in the setting part of the code (which could clear the backslashes and all other kinds of potentially unwanted special characters) or we handle this in the config printing code.

Is there any need to have backslashes in descriptions? Or, more generally: Is there any need to have non-ASCII characters in descriptions?

This should have been resolved by T956, but if it reappears or the fix turns out incomplete, feel free to reopen.

Since most of the work is done and every release candidate of 1.2.0 has been using FRR already, I suppose we should close it. Remaining issues that are causes by FRR incompatibilities should, and are getting their own tasks anyway.

This issue existed in Quagga as well, so I'm simply disallowing decimal notation.

@Line2 Could you attach the IPsec config and the output of "sudo ipsec statusall"?

Could be done by Help text and documentation

right, but not that obvious

Or, if no name-server is set, use the root servers, this is the most easy implementation.

yes, make sense,
maybe we can do
set service dns forwarding name-server use-root-servers
or something similar

If engineid in user node only provides hashing for auth key I would remove it too.
Since we usually not assign engine id automatically it is created for every new hardware installation automatically, so hash of auth key became not transferable. In this case we have to keep plain text password for snmpv3 in our config store, because of automation of provisioning. But I would to keep hash instead of plain text credential.

I would remove the user engineid. I can't see any useful benefit.

in VyOS 1.2.0-rolling+201811240337 I get no proposals and no traffic in 'show vpn ipsec sa':

I just retested on VyOS 1.2.0-rolling+201811240337. Problem is gone.

@dongjunbo Perfect. So it looks like that you have a valid ppp session established (session id 0x5d58). Does 'sudo ip sh a' show you a ppp0 interface or something similar? I tested the ppp client shipped in rc7 and rc8 and it appears it works as expected, so we need to find out what's going wrong on your side.

BBR was enabled in the latest commit to vyos-kernel

Hmm, please enligthen me. Google BBR is a new way to handle congesition instead of the traditional way tcp deals with it. This functionallity needs to be enabled in the end host systems starting the tcp session to have any impact on troughput and congestion control.. as vyos is a router and are not responsible to start tcp sessions on behalf of any end system, what is the benefit of adding this functionallity?

If you want to me run the command on rc8, I need to do it on Monday. Because When i reboot it. my lan connect to vyos will be lost.

Sorry for late responding.
I run the command on vyos 1.2 rc7 :
Here are the output:

Merged from current into crux branch.

@patrickbrandao Your input is required.

@dongjunbo Your input is required.

https://vyos.readthedocs.io/en/latest/services.html#pppoe-server

Thank you!

I managed to get some reproducible captures today. Life took me for a bit of a ride so I didn't have free time until just now.

@m.tremer added the patch, thanks... was under the impression cloud-init added the user as it is stated as default user, but clearly it does not.

Isn't that how Open Source is supposed to work? :)

Good idea, thanks! I've applied the patch and will push it shortly.

For the ones who want to follow or having an early glimpse: https://github.com/hagbard-01/vyos-1x/tree/IPoE

Will be in the next rolling release.
https://github.com/vyos/vyos-world/commit/fb3c399ffad359ec11660e723fb72b9864710029

CI integration pending.

@patrickbrandao Can you please let me know how I can reproduce your issue?

note to myself:

• implement verify for auth mode so that either local or radius is set. :done:

Okay, that is good to know. Unfortunately documentation is heavily outdated. However, I found a fix for this problem which I attached to this message as a patch.