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?

https://github.com/vyos/vyos-1x/pull/53

Thanks. I see if I can add it., can you please request access from @syncer?
@c-po Do you think the updates should be ported then to vyos-documentation or should the new content always be in vyos-documentation?

https://github.com/vyos/vyos-1x/pull/52

@runar Yeah, but it doesn't know about the reboot scheduled via at when you call commit-confirm. I have a look today, it's the last missing piece, I patched already the vyatta portion yesterday. I will leave a comment in th code with the task number, once these vyatta scripts are supposed to go away, it's easy to remove the code.
I was about not to cross call scripts, each script should be able to run for its own with no dependency to other op-mode/conf-mode scripts.

So far only the show command is not working, the at job removal is working correctly.

@runar not your fault buddy, it was never supposed to work like that, at least what I see in the scripts. The actual real broken thing is, that after a reboot the at job wasn't removed, everything else works as expected. The show reboot would be a feature request, I may implement it as well, but I'm not sure if we should leave it with atd. I would rather see in powerctrl.py.

https://github.com/hagbard-01/vyatta-config-mgmt/tree/T870

That function more broken than I thought. I have the fix for acting correctly when it reboots, however I found that it is supposed to accept a time after commit-confirm as well, not only y. Also if commit is called after commit-confirm, it does not remove the at reboot job. Looking into that next.

@dmbaturin You want to implement it or shall I?

It creates a /var/run/confirm.job field which contains the atd ID. So I was more thinking I extend the at command they have in their script. It creates a rollback of the config, applies it then I would just executed the job deletion and reboot. I didn't find any other atd reference, but not sure if there is one hidden somewhere.

I found multiple issues with the old scripts, but I should get it working since at is only used for that particular reboot job.

That was never working as far as I see in the code. Did it work in any 1.2 version?

Bug confirmed.

Thanks a lot. I tried to reproduce it on various machines without success, which leads me to the assumption that the issue might be the NIC firmware. I just had e1000 to test with, but that's all working fine.
Can you please check the following:

Can you please share the output of the command 'show conf comm'. thx.

Hang on a sec, have a look here:
https://github.com/vyos/vyos-documentation

Anyone able to quickly test radius authentication, otherwise I gotta build myself a freeradius first.

Thanks a lot. Let me know if you need anything from me.

I asked in the forum if anyone still uses pptp, since windows can now finally ipsec too, I doubt that it is still in use anywhere. I put the pptp implementation on hold and focus on pppoe for the time being.
https://forum.vyos.io/t/pptp-aka-poptop-still-being-used/2518

I started with it but it's far away from being finished, since I jumped on wireguard first and am currently on pppoe (accel-ppp).

https://github.com/hagbard-01/vyos-1x/tree/T835

Sep 19 21:59:29 vyos accel-pptp: accel-ppp version f7074fe7acf69faab1eec87d97e50df20551429f
Sep 19 21:59:47 vyos accel-pptp: eth1: recv [PPPoE PADI 08:00:27:2c:86:02 => ff:ff:ff:ff:ff:ff sid=0000 <Service-Name > <Host-Uniq 320c0000>]
Sep 19 21:59:47 vyos accel-pptp: eth1: send [PPPoE PADO 08:00:27:5e:e4:00 => 08:00:27:2c:86:02 sid=0000 <AC-Name accel-ppp> <Service-Name > <AC-Cookie fd6d0db4854a2b3bd035dbf33d805ede449c128c52364d1a> <Host-Uniq 320c0000>]
Sep 19 21:59:47 vyos accel-pptp: eth1: recv [PPPoE PADR 08:00:27:2c:86:02 => 08:00:27:5e:e4:00 sid=0000 <Service-Name > <Host-Uniq 320c0000> <AC-Cookie fd6d0db4854a2b3bd035dbf33d805ede449c128c52364d1a>]
Sep 19 21:59:47 vyos accel-pptp: eth1: send [PPPoE PADS 08:00:27:5e:e4:00 => 08:00:27:2c:86:02 sid=0001 <AC-Name accel-ppp> <Service-Name > <Host-Uniq 320c0000>]
Sep 19 21:59:47 vyos accel-pptp: eth1:: lcp_layer_init
Sep 19 21:59:47 vyos accel-pptp: eth1:: auth_layer_init
Sep 19 21:59:47 vyos accel-pptp: eth1:: ccp_layer_init
Sep 19 21:59:47 vyos accel-pptp: eth1:: ipcp_layer_init
Sep 19 21:59:47 vyos accel-pptp: eth1:: ipv6cp_layer_init
Sep 19 21:59:47 vyos accel-pptp: eth1:: ppp establishing
Sep 19 21:59:47 vyos accel-pptp: eth1:: lcp_layer_start
Sep 19 21:59:50 vyos accel-pptp: eth1:: fsm timeout 9
Sep 19 21:59:50 vyos accel-pptp: eth1:: lcp_layer_started
Sep 19 21:59:50 vyos accel-pptp: eth1:: auth_layer_start
Sep 19 21:59:50 vyos accel-pptp: ppp0:test123: connect: ppp0 <--> pppoe(08:00:27:2c:86:02)
Sep 19 21:59:50 vyos accel-pptp: ppp0:test123: ppp connected
Sep 19 21:59:50 vyos accel-pptp: ppp0:test123: auth_layer_started
Sep 19 21:59:50 vyos accel-pptp: ppp0:test123: ccp_layer_start
Sep 19 21:59:50 vyos accel-pptp: ppp0:test123: ipcp_layer_start
Sep 19 21:59:50 vyos accel-pptp: ppp0:test123: ipv6cp_layer_start
Sep 19 21:59:50 vyos accel-pptp: ppp0:test123: test123: authentication succeeded
Sep 19 21:59:50 vyos accel-pptp: ppp0:test123: ipcp_layer_started
Sep 19 21:59:50 vyos accel-pptp: ppp0:test123: pppoe: ppp started
Sep 19 21:59:50 vyos charon: 09[KNL] 192.168.0.1 appeared on ppp0
Sep 19 21:59:50 vyos charon: 11[KNL] 192.168.0.1 disappeared from ppp0
Sep 19 21:59:50 vyos charon: 13[KNL] 192.168.0.1 appeared on ppp0
Sep 19 21:59:50 vyos charon: 15[KNL] interface ppp0 activated
Sep 19 21:59:50 vyos systemd-sysctl[2614]: Overwriting earlier assignment of net/core/rmem_max in file '/etc/sysctl.d/99-sysctl.conf'.
Sep 19 21:59:52 vyos ntpd[2135]: Listen normally on 8 ppp0 192.168.0.1 UDP 123
Sep 19 21:59:52 vyos ntpd[2135]: peers refreshed

Sure thing, I'll leave the bug ticket open.

Hmm, sorry I don't have any windows machine, actually since 1996 I don't have any windows. So I can't test that. I tested with the build from 17th and also with your nat rules, still can't reproduce your issue you seeing. You can check on https://downloads.vyos.io/?dir=rolling/current/amd64 the isos, it goes back till Sept 5th. Or the other option is ti install just a different kernel.
If you need help with installing your own kernel, let me know.

I tested your sniplet and can't reproduce your issue.
Why is your arp requestor a broadcast address?

Can you share your config please.

Getting close to finishing it.

@msbone used the version I mentioned and confirmed functionality. We have to find out what's wrong with the kernel build https://ci.vyos.net/job/vyos-kernel/142/

Last clean version is: https://downloads.vyos.io/rolling/current/amd64/vyos-1.2.0-rolling%2B201809101921-amd64.iso

https://downloads.vyos.io/rolling/current/amd64/vyos-1.2.0-rolling%2B201809120337-amd64.iso seems to be a non-functional build. When I boot it from scratch it drops me only into initramfs. @msbone did an upgrade on hist system from 1.2.0-rolling+201808171757. I advised him to the use the is o from Sept. 10 which I tested for it's functionality. I see if I can find out what happened with the latest build. IT' a kernel module load issue I can reproduce already when booting the iso.

4954.412990] wireguard: loading module not compiled with retpoline compiler.

/etc/logrotate.d/frr exists.

documentation needs to be done.

Sorry, I'm done with that crap.

I get an error message 'contains contacts', plus wasting my time with captchas. I'll write the documentation once that has been solved or just publish a link.

fixed: https://github.com/vyos/vyos-1x/pull/50
(VyOS 1.2.0-rolling+201809082151)

T836 will fix that, which is currently being rebuild in ci.

Ok, so the issue with using messages is that it is defined in rsyslog.conf, which overrules then rsyslog.d/*.conf. I'm gonna get that fixed, back then I wasn't sure how to handle it and when I asked, I never got an answer. I'm going to implement your proposal and /var/log/messages will the global default (tail uses it via monitor too). The file vyos-rsyslog will be removed.

Yes and no. The /var/log/messages config is generated somewhere, I was asking about that while implementing. The problem was as far as i recall, that your settings in the cli aren't applied when you reboot. If you change something in the syslog config it will be accepted and then restart rsyslog and all is well. Then I got distracted with the wireguard implementation:).
I have a look today, thanks for letting me know.

https://github.com/hagbard-01/vyos-1x/tree/T833

Yeah, but I gotta check if it's still correct. We are using rsyslog now and I rewrite the entire thing, I kept in mind staying backwards compatible, but I also introduced a few minor features. Later on, I was thinking to add options for logging directly into databases, right now you can only send via syslog to another server. Also I fixed option which never worked in the original implementation. For instance you can create a debug user, once that user logs in, he sees all messages on the screen etc.

Of course you can:
'set system syslog global archive file <number>'

It depends what you log, if you log everything you may encounter out of space issues. Logrotation is being executed on a daily basis, 6:25 am per default.
/var/log/vyos-rsyslog for instance is being rotated every day. You can do a 'du -sh /var/log/*' to find out what file became very big and then it depends what's in the file etc.

@mrjones Do you finish the documentation?

built a test setup for pptp, which works nicely, so I start with the implementation for the pptp replacement first.

Why not doing it via NNTP group or mailing list? I live pretty close to the 'edge' of the world (UTC -8) but would be interested to stay up to date on what your guys decide. @c-po was so far my mentor here and I asked him to get some ideas how you do things here.
Just my two cents.

I'm going to leave this task still open for a few days to track any issues, if nothing comes up, I'll close it off this week. Meanwhile I have a look into the documentation part, since more functionality has been added and some paths have changed (peers for instance).

merged via: https://github.com/vyos/vyos-1x/commit/d31d16d38c191a8973d79302b108db7276aef7fd

Before I trigger the PR, I'd like to review it once more, I found a few things I may optimize later. I kept the focus strictly on stability and reliability when running it via cli.
https://github.com/hagbard-01/vyos-1x

@Watcher7 fixed via: https://github.com/vyos/vyatta-cfg-system/pull/75/files, should be in the next rolling iso.

@Watcher7 /opt/vyatta/etc/netdevice.... found it, I try

I'm gonna have a look asap, currently a little stuck with private live and preshared keys.

preshared-key implementation progress: https://github.com/hagbard-01/vyos-1x/tree/T793

pre-sharedkey is the last item to implement, before I can close this task. everything else has been implemented via https://github.com/vyos/vyos-1x/pull/46.

done via: https://github.com/vyos/vyos-1x/pull/46

@c-po yes, Sir not a problem at all, takes less than 30 secs. to implement. Once I know how to proceed with the sonarcloud issues...

mtu implementation has been added for review, currently there seem to be a few issues with integration, so if you need it you can rebuilt the package via dpkg-buildbackage -tc -us -uc and download the sources from here: https://github.com/hagbard-01/vyos-1x

ICMP Type 3, Code 4 messages are generated by the kernel, pmtud is not a wg feature, but I hear you. I see that often that ICMP is filtered away in general and that can create you a lot of grief. It's been always on my list since I started the implementation.

https://github.com/vyos/vyos-1x/pull/44
I cancelled #43 due to the sonar issues.

https://github.com/vyos/vyos-1x/pull/44