Looks good first glance to me. Next rolling will have it included.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Oct 21 2019
Oct 20 2019
Can you please test installing this package and feedback to me?
@pvelati thanks for the update!
hi @c-po , I've tried installing the 3.8.3 version but it's not compatible with the new CloudFlare API v4. The only way to make ddclient working with cloudflare is using the 3.9.0.
vyos@vyos:~$ wget http://ftp.de.debian.org/debian/pool/main/d/ddclient/ddclient_3.8.3-1.1_all.deb Connecting to ftp.de.debian.org (141.76.2.4:80) ddclient_3.8.3-1.1_a 100% |********************************************************************************************************************************************************************************************| 81924 0:00:00 ETA vyos@vyos:~$ sudo dpkg -i ddclient_3.8.3-1.1_all.deb (Reading database ... 59343 files and directories currently installed.) Preparing to unpack ddclient_3.8.3-1.1_all.deb ... Unpacking ddclient (3.8.3-1.1) over (3.8.2+vyos2+current1) ... Setting up ddclient (3.8.3-1.1) ...
Even better, looks like wimpunk is maintaining again and there is a fresh release https://github.com/ddclient/ddclient/releases 3.9.0
Debian Buster uses 3.8.3 https://packages.debian.org/buster/ddclient which could be considered as using a proper source tree.
@dmbaturin bump? I'd like to submit a PR for this issue, but would like some guidance regarded to my comment above.
Oct 19 2019
Okay, thanks for the info.
It is true what @Viacheslav say, there is only possible to run one instance of bgp om a given router.. when using vrf's the bgp running inside the vrf is a subset of the main instance. to confirm, start vtysh and try to create multiple processes.. it will likly fail :)
We are a little confused.
As far as I know, Bgp instance on all router's platforms always one.
And it use socket with 179 tcp port.
VRF is working on same bgp instance, but support multiple autonomous system at once.
Agree with you, thank you. We need fixed these moments.
Unfortunately it doesn't work without gw-ip-address also in [chap-secrets]. In my early trials I've tried that, and the clients received IP's from the pool instead the static values.
I think better calculate gw-ip-address automatically. outside-nexthop excluded from required for migration reasons.
Not necessary define gw-ip-address in [chap-secrets] section, it works without any issue if defined it in [ip-pool] only.
@Dmitry Thanks for pointing that out, I've looked on the wiki (https://wiki.vyos.net/) and searched for a description for outside-nexthop, and failed to find it, and the in-line help while configuring doesn't help much.
You can set outside-nexthop which fixed this. Also I think we can calculate first ip for gw-ip-address if outside-nexthop is not defined by cli.
@runar at the current time this is true only one BGP instance is supported. But when we incorporate VRF one day which is definately on the roadmap this could change.
Verified in VyOS 1.2-rolling-201910190658
As for my understanding frr only supports a single bgp instance running at a time. But i've not verified thid completly.
ISO has been pulled. Next rolling will have the fix.
What about upcoming VRF when we possibly have multiple bgp processes?
This is already fixed in vyos-1x package but there is currently a problem with the CI.
Out of curiosity, I tried 201910170117, and it was fine (at least for booting). The 20191018 image may be broken - should it be pulled?
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.
Oct 18 2019
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?
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.
vyos@vyos# set interfaces wireless wlan0 Possible completions: + address Address for this interface > bridge-group Interface bridge group > capabilities HT and VHT capabilities for your card channel Wireless radio channel debug Enable hostapd logging to syslog description Description for this interface > dhcpv6-options DHCPv6 options disable-broadcast-ssid Disable broadcast of SSID from access-point disable-link-detect Ignore link state changes on this interface expunge-failing-stations Disassociate stations based on excessive transmission failures. > firewall Firewall options hw-id Media Access Control (MAC) address > ip IPv4 routing parameters > ipv6 IPv6 routing parameters isolate-stations Isolate stations on the AP so they cannot see each other mac Media Access Control (MAC) address max-stations Maximum number of wireless radio stations mgmt-frame-protection Management Frame Protection (MFP) according to IEEE 802.11w mode Wireless radio mode physical-device Wireless physical device > policy Policy route options redirect Incoming packet redirection destination reduce-transmit-power Transmission power reduction in dBm > security Wireless security settings ssid Wireless access-point service set identifier (SSID) > traffic-policy Traffic-policy for interface type Wireless device type for this interface [REQUIRED] +> vif Virtual Local Area Network (VLAN) ID
Why bot simply create /etc/wgetrc? Can curl read that file? If not, /etc/curlrc.
Oct 17 2019
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.