This is present in branches crux and current too, so adding tag for crux.
https://github.com/vyos/vyos-1x/commit/5848a4d6095e6d7bc70e34e0b7b7e2c3d8e3303f
https://github.com/vyos/vyos-1x/commit/6f954ab56768af9a07d8a1dc086f54ddefa58da7
https://github.com/vyos/vyos-1x/commit/5848a4d6095e6d7bc70e34e0b7b7e2c3d8e3303f

Via the process of elimination I found the culprit - comments with special characters in them, that at some point in the upgrade cycle got converted into backslash-escped decimal:

description "\197\160" # this was once Š
description "\196\140 \196\141" # Č č

\197\160 is C5 A0 which is U+0160, which was the original character.
So old versions allowed these characters in comments and worked fine with them, then at one point an upgrade converted them to backslash decimal UTF-8, which still worked until at some point they started causing the error.

works with:

Version:          VyOS 1.2-rolling-201910110117
Built by:         [email protected]
Built on:         Fri 11 Oct 2019 01:17 UTC
Build UUID:       48a11fa6-8c59-4dbb-94a3-215376c09a02
Build Commit ID:  46f9b2ab60e4fa

Can't create an iso right now to test it.

typo fixed: https://github.com/vyos/vyos-1x/commit/50acd442ade9a4e447269eaf94ce14d354af8d0c
http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyos-1x/vyos-1x_1.3.0-16_all.deb should work now

Okay, after working with this for a while, I believe the whole 'vyatta-webproxy` should be a candidate for deletion in equuleus (see T1732).

To be fair, that’s what prompted this. The logs go to a different file already.

Because the amount of logs from this system could be enormous, Is it possible to move these logs to another syslog file to not overcroud the main syslog file?

This PR should address those concerns

I would rather prefer it to send messages to local syslog and then distribute it to remote hosts. Otherwise we have an async syslog interface.

Okay - just installed the latest rolling and it does not even boot up anymore. Its trapped in a snmp restart loop somehow. Going to revert this commit.

The change now leads to not starting SNMP when I do not use BGP

Found it.

Yes I was running from a live image exactly as hagbard mentioned.

running from the live-cd I think.

@brian.ward no problem. Could you please tell us what was your problem so we could probably reference this in the future for other people?

Sure enough, /config is not mounted.
Not sure how the configuration was being saved.

@brian.ward Please show the output of df-h at your earliest convenience.

@hagbard yea if there's no way to do it, there's no way to do it. Thanks though.

@bertleywjh any other input, or can I close the ticket?

@brian.ward I just tried to reproduce this with a clean VyOS installation and it works as expected.

Absolutely, I was going to paste a screen shot of the running config.
I’m eating lunch let me respond when I get back if that’s alright.

Looks like it has changed already in ifconfig.py. Tested it successfully as well.
https://github.com/vyos/vyos-1x/commit/f5c04661e6c031baedb6092ecafee501cca7bc28#diff-def38e05f2ac1eb35139b37ec8d47338R1375

No problem, I had already made the change manually in the snmp.py file. Since then, the problem has not occurred.

I‘d simply override the set_state() function in derived WireGuard Class without that check. If more interface have this (possibly VXLAN) it could be added to baseclass with a flag that the particular code is not executed.

@cpo operstate will be unknown for wg interfaces, I think it's the only interface type having unknown. Anything else should be up or down, I think. I can re-implement with the wg class if that's better.
Let me know what you think, wg is working with no issues, so functionality isn't an issue here.

@bertleywjh wg state and link state is all is unfortunately all you will be able to see, plus like when was the last handshake and how many bytes were transfered. AFAIK there is no other way to see states of the handshake etc.

@hagbard

show interfaces wireguard wgN

This just shows general configuration info & link state.

@fvbrasileiro here you go: https://downloads.vyos.io/rolling/current/amd64/vyos-1.2-rolling-201910102056-amd64.iso

@fvbrasileiro Yeah, we found that out too today, we are working on a solution already. Please be patient.

In T1705#44982, @hagbard wrote:

@fvbrasileiro Please test at your earliest convenience.

https://github.com/vyos/vyos-1x/commit/e45648cdd5a52569be7f3ac30473b0c7474a7894
http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyos-1x/vyos-1x_1.3.0-16_all.deb

Next rolling will have it: https://github.com/vyos/vyatta-op-quagga/commit/219265ae4c8886bb6997ffc79f34610d6e2ea2d0 or you can manually install from the source below, if it is an urgent matter.

The cli part for the routing suite is up for rewrite, json is only working because it's supported by frr and the cli doesn't filter it. I think getting show ip route tag 20 working shouldn't be a big deal, but I try to avoid to add too much to the cli, will make just the rewrite way harder.

@hagbard via a route-map for example. set policy route-map TAG rule 10 set tag 33

There were multiple complains about bgpd crashes, memory issues inthe forum. They used the workaround removing the tables from snmpd successfully.

@olofl How do you set the tag? via CLI?

I do not see this problem on a full table v4/v6 router with 2 cores 4 GB RAM. The question is why? Is removing the table a good idea? What was the state with 1.1.8?

@fvbrasileiro Please test at your earliest convenience.

I can confirm the issue. Actually it boils down to two individual ones.

It is an upstream issue so I agree totally in closing as wonˋt fix

Shall I close it as won't fix, given the fact that it is an upstream issue. Anything build around it, is in my opinion just a kludge, unless we would go with a separate daemon which can check and re-establish connections if they fail. The danger is that vyos becomes then more a server than a router. As workaround, a cronjob could do that as well, either setting an option via cli (wg-heartbeat or so since keepalive is a wg option already), which drops a cronjob onto the box and checks the wg endpoint periodically, if it fails it just calls diable/enable and checks again for X times, before it sleeps for let's say 24hs or so. @kroy would something like acronjob help you? Could be also set as a @reboot job and once the traffic flows it kicks itself out. Just wanna throw out ideas here.

FYI: https://git.zx2c4.com/wg-dynamic/about/docs/idea.md

The Linux kernel has embedded name resolution, maybe this can be added to WireGuard itself. Its better then we design a patch for it.

reverted the commit. I'm not sure if a daemon would be a good idea. Another option is to allow only IP's entered via cli or checking the name whenever wg is executed, resolve the name and send it to hostd to get it written to /etc/host. That would solve at least the issue at reboot and in most cases the correct IP should be in /etc/hosts.

@kroy just to be clear, i'm not against using dns as endpoint for wireguard.. i'm for it, because i have the same issue as you do, but what i'm against is the way to getting there. As the wireguard protocol does not support dns in it self using this method is a loosing game.. what i'm not against is writing a daemon that does the name resolution for you when it comes available.. and available could mean after 1sec, 1m, 1h or even longer after the system is booted.. this daemon also could do re-resolving when the peer is down and the dns has changed...