- User Since
- May 2 2016, 7:40 PM (272 w, 4 d)
Wed, Jul 21
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.
Sat, Jul 17
I have made a second attempt of the PR: https://github.com/vyos/vyos-1x/pull/928
The original 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 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.
Wed, Jul 14
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 and 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
Mon, Jul 12
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.
Dec 31 2020
I used dnsdist and dnscrypt-proxy before but currently I settled with:
Mar 9 2020
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:
Feb 23 2020
Aug 10 2019
May 29 2019
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.
May 17 2019
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.
May 4 2019
So is it considered a bug or works as intented?
May 2 2019
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?
May 1 2019
Apr 25 2019
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.
Apr 24 2019
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
Apr 23 2019
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?
Apr 22 2019
@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.
Apr 21 2019
Attempt two of the fix, so disregard everything in above attempt.
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.
Apr 16 2019
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?
Feb 17 2019
Feb 11 2019
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.
Dec 7 2018
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
Nov 26 2018
Nov 20 2018
Nov 13 2018
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.
Oct 13 2018
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:
Mar 29 2018
Is there any progress on this merge?
Sep 2 2016
It would be nice if this was available in the next release. Happy to receive any feedback if I need to improve the patch.
May 11 2016
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
May 10 2016
I already have a working patch for my own setup, I attached it: