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.

I'm going to verify @dmbaturin patch to set level to info. Additionally we could also use immark, which leave a 'heartbeat' marker in the logfiles, so one can verify logging at least works. It would be visible to remote logging as well.

It's not really a bug, the log level is per default set not to log everything, like @EwaldvanGeffen stated above.
'set system syslog global facility all level all' will log everything, embedded users with flash drives will hate us for this if we change it :).
In my opinion, if someone needs to debug anything, he/she can just set the global logging or even to a particular file for debugging.
Otherwise, we can just change the section in the default config to have logging anything enabled per default, which increases the risk for losing information due to disk space limitation for /var/log as well as the quicker rotation (only 5 files are being stored per default).

What about adding the package list of all installed packages to 'generate tech-support archive'?
It adds already:

Wasn't an issue, it's handled properly via frr.

verified via latest rolling iso.

@dsummers no problem at all I found a few issues in the existing code, plus I had to read up on the virtio code as well :).

https://github.com/vyos/vyatta-cfg-system/commit/bf7fe3da15446eef6d5974d26106c130179c32fc
The function set_speed_duplex checks the setting via ethtool again and compares it with the requested ones, since virtio_net returns 'unknown', the setting have been applied only every 2nd commit.

Found another weird bug in the vyatta script, it applies duplex and speed only after 2 commits.

verified availability.
VyOS 1.2.0-rolling+201810160337

That needs to be handled with care, since the old perl script have some easter eggs in it.

https://github.com/vyos/vyos-build/pull/26

https://github.com/vyos/vyatta-cfg-system/pull/79
I test it tomorrow after the CI rebuild before I close this task.

@syncer we have this patch in the kernel (commit 16032be56c1f66770da15cb94f0eb366c37aff6e ++). I think ethtool just doesn't use it, which is what I'm gonna check next.

@syncer gonna have a look today.

https://github.com/vyos/vyos-build/compare/172c65f07503...b2476e3bd0ab

Should it be disabled globally, or just not loaded vi config?