Hi, this bug is introduced again in VyOS 1.4 (tested VyOS-1.4.0-rc1). Due to the following commit: https://github.com/vyos/vyos-1x/commit/64c9fdef02323309e97b2bb682604ada52d651e8

Is there anything I can do to improve this PR? I also noticed that there is no more example commit-archive output since vyos 1.4:

Would also be nice to include the global known_hosts file in /etc/ssh/ssh_known_hosts.

I would also like to know if zone based firewall still work or support is removed?

In T2405#159522, @Apachez wrote:

Note that command = command.lstrip() for def cmd in python/vyos/utils/process.py was reverted yesterday.

Causes funny problems during smoketests.

I created a PR for Git support here: https://github.com/vyos/vyos-1x/pull/2241

Confirmed fixed, static address is correctly assigned after resume. Tested with vyos-1.3-beta-202108192027-amd64.iso

Confirmed fixed, tested with vyos-1.3-beta-202108192027-amd64.iso

Want to test latest rolling iso, but equuleus seems to be stuck at vyos-1.3-beta-202107121144-amd64.iso which doesn't have this fix yet.

I have made a second attempt of the PR: https://github.com/vyos/vyos-1x/pull/928
The original tls configuration checks are back, but it's only checked if no alternative authentication methods are configured.

As I suspected, it check if the ConfigSession properly errors if "tls cert-file" and "tls key-file" are NOT defined (for server):

Hmm. Can you point me to the smoketest that failed? I will investigate. Maybe it actually tests if the strict check are in place, because now cert-file and key-file are optional, but it should keep working if you configure it.

I submitted a PR for review: https://github.com/vyos/vyos-1x/pull/923

It's funny, I remember that dhcp was already removed from ether-resume.py. I checked the git history, and it was.
Related issue and discussion about netplug vs ether-resume dhclient (buried deep in the beginning) https://phabricator.vyos.net/T1028

PR: https://github.com/vyos/vyos-1x/pull/920

PR submitted: https://github.com/vyos/vyos-1x/pull/917

The workaround stopped working after the OpenVPN configuration checks moved from Perl to Python. As this still applies to VyOS 1.3 this issue should be reopened, I can also create a new issue if that is preferred.

I used dnsdist and dnscrypt-proxy before but currently I settled with:

Thanks for the quick fix c-po, I noticed this also needs to be fixed in /usr/libexec/vyos/op_mode/reset_openvpn.py in case someone runs for example:

Hi Donny,

Not much response, but multiple users I recommend VyOS to are having this issue. So i would say it's a bug and not intended behaviour.

Sorry comment on a resolved ticket, but i'm having the issue that is described in this issue. And i'm not sure how to fix it.

So is it considered a bug or works as intented?

If that is the only point, race conditions can occur. I assume this is only called when comitting or loading the config.

When is host_name.py called? Maybe my dhcp server just responds slow and host_name.py is called before dhcp server responds? Is that possible?

Yes, it's pretty vague bug, and seems it's more related on how the VM was initially created if it will work or not.

hi @hagbard, I did some extensive testing. Actually I was already testing with "1.2.0-rolling+201904240337". So here are my findings.

Because you mentioned networkd earlier, I looked into this immediately and found the following differences:

Thanks, I tested it, my findings below:

When I read it back, I can understand the confusion. Sorry, will try to be more clear next time.

@hagbard But we were talking about my patch, and that it didn't work for you in latest rolling... So i tested my patch in the latest rolling (and noted the date) that it worked. Should I have made it more clear that I was testing my patch?

Hi hagbard, I don't understand why you close the PR so early without me testing the latest iso. Please when you refer to "latest" iso, to also note the rolling date. This makes it easier for everyone who tries to contribute i think.

Thanks for the detailed history, that makes things more clear.
So for me the latest rolling worked, do you know what part from networkd is interfering with dhcp for you? Did you see if netplug called dhcp correctly after resume?

I wonder what changed then, will also test with latest rolling

PR: https://github.com/vyos/vyos-vmwaretools-scripts/pull/1/commits/92f5d450df4de09626af232bc5ced067a6493d6b

Ok final attempt and trivial fix.
It seems that changing run-parts to /bin/run-parts was not needed. So netplug works fine as it is.

Hi all, I can confirm that with vyos-1.2.0-rolling+201904160337-amd64, this issue is fixed.
If I boot the older 2019-02-16 version, the bug can be reproduced easily. So it must be an issue in FRR that is introduced in 7.1 as the newer livecd uses FRR 7.0:

Is this a FRR bug or something else? Because I don't use any BGP stuff I just added the ip -4 route add command to my VM, so it's always executed. However, as @runar mentioned, it will bypass FRR. But executing the command via FRR didn't work, so the issue must be in FRR?

@hagbard Can you please test the steps I mentioned mentioned here, to see if you can reproduce: https://phabricator.vyos.net/T1028#35591
Without any modifications to any scripts, it will bring the interface into permanent down state after suspend and resume.

Attempt two of the fix, so disregard everything in above attempt.

I have a working fix, which is comprised of earlier suggested fixes I mentioned in T1028 and T894:

I want to set this ticket back to "Needs testing" or even "Open", I have downloaded and tested vyos-rolling-2019-04-16 and it seems it is not properly fixed.

In T1250#35137, @UnicronNL wrote:

@yun What is the exact frr command you tried?
the command you tried manually.

I would to see this committed. But do we also know what causes the issue? Is it with FRR or was this script just missing the ip command to set the default gw?

Just to add extra info to this ticket, I had a openvpn-option that i wanted to add but it contained a single quote. I was not able to do this (in version 1.8.x this worked).

I was not able to test sooner. But i confirmed it works properly with rolling release vyos-1.2.0-rolling+201902060337-amd64.

Will you then use the netplugd way mentioned in T894 or also issue a dhcp renew in the resume vmware script? I prefer the netplug way as this also fixes issues when you switch network. I can imagine we want to avoid double renewing.

@hagbard I tested the script, it works perfect for interfaces with static addresses. However interfaces with "dhcp" remain without an ip address after resuming. This is caused by the following issue I reported: T894

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.

Actually the old netplug script doesn't fully work, i had to use the original netplug script that comes with the package but I added the run-parts lines like this:

Hi, I requested this feature, but due to the addition of username/password it can work as a good workaround.

I did some of my own digging, and it seems because Vyos 1.2.x is missing the netplugd daemon.

Now that we can add user-pass authenticaton so the configuration is accepted without cert and keyfile we can fool the configuration to make it accept and work with pkcs11 settings:

Is there any progress on this merge?

It would be nice if this was available in the next release. Happy to receive any feedback if I need to improve the patch.

Maybe make the tls cert-file and key-file complete optional, this way other advanced options can be used for openvpn by using "openvpn-option", such as pkcs11 support mentioned in T56

I already have a working patch for my own setup, I attached it: