run sh ip route

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:

I tested everything, pppoe client is working correctly. @dongjunbo Can you please do the following:

I tested all is fine. So it must be something else. I found an issue in the pppoe-server code which was supposed to be released, but weren't. (local auth isn't working, rolling release has the latest code already in).
Other than that, the ppp client in rc8 is just fine, I created a pppoe server (vyos rc8) and used another vyos box (rc8) as client, no issues at all.

@dongjunbo , @syncer
The ppp client hasn't been removed, the old pppoe-server packages was a bunch of scripts utilizing rp-pppoe. I have a look into rc8, the rolling images have the client on board (ipsec l2tp would otherwise fail as well).
I'm gonna test a fresh install and have a look into your config.

I can't reproduce it @patrickbrandao. can you please detail out of what you did?

I'm going to keep this task still open till the end of the week to catch eventual bugs.

@sokrates No problem at all, whenever you have time.

@sokrates Can you please test with the latest rolling release?

In case someone else finds it helpful:
http://telecomsite.ru/upload/news/using_pppoe_and_ipoe.pdf
Gonna start shortly with IPoE implementation.

https://github.com/vyos/vyatta-netflow/commit/3562ed47b5f897d09ba01c5d2cdc3bfbb1ee253b

Ahh crap. I'll fix that right away.

https://github.com/vyos/vyatta-netflow/commit/07abd7362b12a8a3c988d223113f6ec7c082638f

bug confirmed in 1.2.0-rolling+201811150337.

Hmm, it works for me flawlessly. Can you try https://downloads.vyos.io/testing/1.2.0-rc7/vyos-1.2.0-rc7-amd64.iso please?

For everyone who wants to test, this version is in rolling releases. If you find any bugs, please post it here.
https://downloads.vyos.io/?dir=rolling/current/amd64

What are the parameters you connect on rs232? Have you tried to switch to 115200 baud after grub started?

feature release for rc8: https://github.com/vyos/vyos-1x/commit/93c9199589cca87321f1f0577d16099dbe78842b

sh version
Version: VyOS 1.2.0-rc6
Built by: [email protected]
Built on: Tue 06 Nov 2018 01:28 UTC
Build ID: c5283369-3c07-4539-97fb-76e701e97a77

What's the problem @sokrates ?

Options added. Maybe I should make a node for dns and have then all dns settings in there for better visibility.
set service pppoe-server dnsv6-servers
Possible completions:

server-1     Primary DNS server
server-2     Secondary DNS server
server-3     Tertiary DNS server

IPv6 pppoe options added.

feature below added:

https://downloads.vyos.io/rolling/current/amd64/vyos-1.2.0-rolling%2B201811092133-amd64.iso

I gotta investigate if that was in 1.1. The NETFLOW target is a kernel module, which is presently not include in our kernel we use.

Pushing to rolling releases tonight.

Tested on the latest, rc.local is executed before the config is applied, which causes the issue.

Step 1 import and debianize from source: https://github.com/vyos/vyos-xe-guest-utilities

can you please share the part of your config addressing this issue? ('show config comm').
Thx.

https://github.com/vyos/vyatta-op/commit/3f33e3d1ce4e4a8dbcbdabd96763c87dfa4e2cff
Uses now journalctl to display all og messages as well as separate auth/authpriv messages.

Added package to vyos-world and rebuilt vi ci.
https://github.com/vyos/vyos-world/commit/97e2b036d0b0eabc68f64f6b8c0c42c96976f038

https://github.com/vyos/vyos-1x/commit/c798e0821c4acbf7ff89e6d2aeb2807cd07f4152
Should be fixed in the next rolling.

bug verified, thanks for reporting.

https://github.com/vyos/vyos-1x/commit/e1abd4f61f31d9ce7c54fe790a30d973aae53ab2

I see.
Compress was never enabled, because of the 'show log' command.
Theoretically, it could be done but I'm not sure if it is really needed due to it's short rotation lifetime.
For the auth log issue, I need to discuss this internally first, I recommend to create your own file with the command I mentioned above if you want to have it logged separately.
Let me know if you need help accomplishing that.

logins or failed logins are already logged in it's default configuration.

Fix will be available in tomorrows rolling release.

bug verified.

https://github.com/vyos/vyos-1x/commit/2ad8fa385cefa1acbe75b8ca22a4183b00edf7de

Yes! Radius auth is working nicely, now the cli config part needs to be finished.

All right, node.tag gets called twice. In the first round both interfaces are being configured correctly, then the parser calls it again (node.tag) and of course the IP already exists, so the error is valid from a script perspective.
Related to the issue @runar reported: https://phabricator.vyos.net/T786.

DNS issue, not wireguard related. Using the endpoint IPs is working correctly.

So far so good. Traffic works when using endpoint IPs a instead of the name, still looking into that, but in general no problem with wireguard found.

Currently only the check for additionally installed packages is implemented, but the script can be extended. Didn't push it to crux to have it properly tested first.

Since I don't know your listen ports I can't verify, if the ports you've set are correct or not. What I see in the logs, looks all ok, please keep in mind that your tunnel shows onl;y active if at least one packet passed the wg interface, otherwise you won't see anything.
So as far as i see from the above your wg interfaces are being created (you can bind multiple different peers to one interface by the way) and active.

I've tested your setup and can't find any issue with the interfaces in -rc4. However your routes won't survive a reboot, please use 'set protocols static interface-route <destination-net> next-hop-interface wg0'.
If that doesn't solve your issue, please check 'show interfaces' and check if the wg interfaces is setup after reboot there.
Also please provide the output of the following:
'grep wireguard /var/log/messages'

Hi @MrXermon ,
can you please share your configuration? At least the set interface wireguard ... ones would be interesting, so I can test it.

@dmbaturin Awesome, I didn't have the time to look into that further. I'm going to test it for sure.

So that's what I have right now for checking the packages, if they are newer than the image build time, it would spit out the below:

You can download it to your route and the just do a dpkg -i wireguard....deb.

http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyos-1x/vyos-1x_1.2.0-3_all.deb

I'll remove the ip-host validator from the wireguard tree, it causes a few issues if the network name is picked as address. e.g. 10.1.1.2/31

https://github.com/vyos/vyatta-cfg-firewall/commit/d4799d1715fc3177b84d66af406fa3028a95d254
pkg checked out ok in ci, tested and verified locally in 1.2.0-rolling+201810211757.

show tech-support network - all network related stuff
show tech-support system - os related (cpu, memory, file system space, pkgs etc.)

https://github.com/vyos/vyos-1x/commit/4029814a1ee22d02748ab92e01c357c66a9f9137 (current)
https://github.com/vyos/vyos-1x/commit/fd0f4529eba75dee6b993ce449987e267a95cfb4 (crux)

ok, so what do you have in mind for integrity support? If someone installs from external sources or a different kernel for instance, you can only find out when you have the information somewhere, that's why I though to integrate it into the tech-support. So, if someone reports an issue, we can just receive that report and have all information in one tarball to check what's going going on. I'm getting a bit confused.

Yeah, I agree but what about the show tech-support which currently exists?
There is generate tech-support archive, which stores a tarball and/or you can upload it via scp/ftp to a destination.
Plus there is 'show tech-support' which shows the information to the screen, which I think won't make a lot if sense.
For the packages, I have the full dpkg -l in a file, that can be read and compared easily with the packages installed in the iso.
Do you have a system for automated checks in mind already? (I built something similar in the past on a normal webserver).

Do we need show tech-support at all?
I changed a few things I would gather, I leave /home/user and /config/auth alone, since they can contain sensitive information like private keys.
In the archive I create files for each 'section. Like OS based information, network related information go to an extra file etc.
The idea is to make it easier for the one reading to all that stuff and giving the user the confidence we don't steal their ssh key or wireguard private keys by accident.
Also adding content to the report would be easier there too. I can upload to my github what I have so far since you would only need the script right now, I haven't it integrated in vyos-1x yet.