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.

This works as expected

I'm still having an issue with using build-ami to create an AMI in us-gov-west-1.

Thanks for your contribution.

https://github.com/vyos/vyatta-cfg-system/pull/109

Perfect. Thanks a lot guys.

As the AS number is a bgp specific attribute i don't think it's wise to move it out of the bgp hierarchy .

@c-po I can't see the issue here, that seems like normal expected behavior (tabbing gives a list of all possible nodes, even the long ones?)
I agree that if there is a problem, it's for a separate issue and describe what the problem and expected behavior is in more detail there.

fixed in 1.2.3

@c-po what you are describing don't look like a bug.. its more like a feature :) anyways its not related to this issue so please open another ticket on this.

I see no reason to add wget as curl is superior. We should set this to Wontfix

@Harliff Does curl work for you?

Is that still and issue, sorry I lost track a little while I was busy with other stuff.

already added to the documentation: https://vyos.readthedocs.io/en/latest/system/proxy.html

good first implementation thx. can you please also update docs?

https://github.com/vyos/vyos-1x/commit/df9544233fb661e830285c1a0d7755cff4b27408
https://github.com/vyos/vyatta-cfg-system/commit/3a99ea6e9b8ef9ef417d38d1d0bab8d2d2401aa8 (add system image)

I have an idea, I can either write it to profile.d, that is exporting http_proxy, https_proxy and ftp_proxy into the shell env, and in the install-image script if the profile files exists, I load it which exposes these variables as well and curl is working with no issue. If removed, that file won't exists and curl works like it did before. If the proxy variables shouldn't be in the user environment, I can write it to a particular file only used by scripts which which would need that information.

curl only accepts ~/.curlrc, so that can become a hassle with multiple home directories on a box.

We only have curl and wget for outside communication so this should be fine, whereas curl is the preferred way - thus this is more then fine and can be altered if its really required. Keep it simple.

Root cause identified and fixed. Please test @albeu.

That would work but it's only for a single programm you define it. I think it could be enough for the beginning. I still have to check if curlrc is being read when invoked from the perl script, it usually should.

Why bot simply create /etc/wgetrc? Can curl read that file? If not, /etc/curlrc.

PR https://github.com/vyos/vyos-nhrp/pull/2

The removal makes a little headache. Setting it system wide is not an issue at all, writing and execute in profile.d. Removing it would require to logout and login again to re-read the bash.profile. I may have to rethink that. Also the image download is invoked via a perl script, so http_proxy will be lost anyway.

I have that issue for a while here too and just helped myself locally. I'll can take care of that.

PR #37

PR #31

The system where I'm seeing this is a VM which use a BNX2 dual port network card via PCI pass-thru. Both ports (eth0 and eth1) are configured in a LACP bond (bond0) with several VIF running on top of it (bond0.10, bond0.20, etc). All VIF are showing this problem.

I have generated a PR for this fix https://github.com/vyos/vyatta-op-vpn/pull/24.
Please take a look at it.

Hi @albeu the fix is very bad in most of our cases and not really good to address a single issue. Can you give some hints to reproduce the "DHCP won't start on some interfaces"? problem?

When we say building is only supported in our Docker environment - is it even an issue? Just patch it during preparation of the container and we‘re all set.

One might need to differentiate between transparent bump-in-the-wire type squid deployments, and running it as a known proxy (delivered via DHCP and an onboard PAC file). Plus any kind of speedbump captive portal. I know one place specifically uses it to force clients to expose connecting hostname due to the use of the CONNECT command for TLS connections, for passive logging on the wire. Which will get interesting with the emergence of DoH and DoT in mainstream browsers, and enterprise efforts to kill that off.

Myself I'm in favor of maintaining a fork and asking people to install it. We can add a version check to the ./configure script to make sure it stops and tells the user what to do if the version is not patched.

Most enterprises use it still as a cheap authentication method, I'm totally in favor to drop it, not only in vyos. Breaking it off (they generate fitting ssl certs on the fly signed with a private PKI), is questionable as well, since I think https should be end to end encryption, everyone who messes with that idea, well I wouldn't trust them on other items as well.

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.

Also, as we are implementing this into the vyos cli, we can only omplement a small subset of the squid functionallity without doing lare efforts on implementing everything.. thats also why i favor to removing this functionallity..

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

+1

+1

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

I will ask on customer survey but i know proxies used in enterprise environments not for caching or blocking but for securing access to public segments

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

@c-po can you provide a way to reproduce your issue?

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.

https://github.com/vyos/vyatta-cfg/pull/19
This fixes the conf mode completion, at least in the bash cli shell.