I can't reproduce it @patrickbrandao. can you please detail out of what you did?
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Nov 20 2018
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.
Nov 19 2018
@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.
Nov 15 2018
Ahh crap. I'll fix that right away.
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
Nov 14 2018
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
Nov 13 2018
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 ?
Nov 12 2018
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
Nov 11 2018
IPv6 pppoe options added.
Nov 10 2018
feature below added:
Nov 9 2018
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.
Nov 8 2018
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.
Nov 7 2018
https://github.com/vyos/vyatta-op/commit/3f33e3d1ce4e4a8dbcbdabd96763c87dfa4e2cff
Uses now journalctl to display all og messages as well as separate auth/authpriv messages.
Nov 6 2018
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.
Nov 5 2018
bug verified, thanks for reporting.
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.
Nov 4 2018
logins or failed logins are already logged in it's default configuration.
Nov 3 2018
Fix will be available in tomorrows rolling release.
bug verified.
Nov 2 2018
Oct 31 2018
Yes! Radius auth is working nicely, now the cli config part needs to be finished.
Oct 30 2018
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.
Oct 29 2018
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.
Oct 28 2018
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.
Oct 27 2018
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.
Oct 26 2018
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.
Oct 25 2018
show tech-support network - all network related stuff
show tech-support system - os related (cpu, memory, file system space, pkgs etc.)
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.
Oct 24 2018
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.
Oct 23 2018
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).
Oct 20 2018
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.
Oct 19 2018
Oct 18 2018
verified via latest rolling iso.
Oct 17 2018
@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 :).
Oct 16 2018
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
Oct 15 2018
That needs to be handled with care, since the old perl script have some easter eggs in it.
https://github.com/vyos/vyatta-cfg-system/pull/79
I test it tomorrow after the CI rebuild before I close this task.