This also affect manually built iso's that also fails because of pdns-recursor
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jul 18 2019
Hi! The rolling release is broken because pdns-recursor has stopped to provide packages for jessie and the current index points to a file that is currently not available. We are working on fixing this and it migth be that we need to start building it ourself instead.
Jul 11 2019
As long as its allowed but not working its a bug.. :)
Jul 9 2019
Jul 6 2019
I've updated all found instances of hardcoded eth instances to also take systemd interfaces names. this will be working when were upgrading to buster.. i've built an iso with these changes and i'm able to set an ip on my ens3/ens4 nic's and it works. for buster this could be a solution on this issue. the question then is if buster comes soon enough to not rewrite these scripts until then.
Jul 4 2019
As i commented : the best i've found is to start using systemd and rewrite all occations that has hardcoded eth name mappings.. but thats a bigger case i think..
As for now, the mapping scheme is done with mac adress=>name, so as long as the mac address dont change and you preserve the persistent interface mapping file you should be all good.. i'm wondering if its possible to migrate from a mac-address mapping scheme to instead use eg. Pci index.. but havent found any good solution on this.. the best i've found is to start using systemd and rewrite all occations that has hardcoded eth name mappings.. but thats a bigger case i think.. so for now it's going to be mac address=>name
Jul 2 2019
The issue here is not the scripts themself, it is our(vyattas) mixing of hardware/ system configuration.. the ethernet mapping table is a device specific table that only works on one particular device, all other configuration inside vyos is portable between devices, but this information is not.
This also makes it impossible to move a config file to another hardware without modifications (removing the hw-id mappings)
Jul 1 2019
Jun 30 2019
Hi rob! Nize that more people is involved in this :) i've started the large task of marking things that have been migrated to github, it's a lot of pages with outdated info thats not going to be migrated, also i find a lot of pages not having enough "end user" documentation that i don't know where to put.. eg. devel docs etc..
Jun 29 2019
and always download the latest upstream driver
i think that out-of-tree drivers also needs to be under the same control as modules and the kernel
Jun 22 2019
with my last post in mind, here are the workings of a cisco IOS loopback:
router(config)#int loop 123 router(config-if)#ip addr 1.4.4.1 255.255.255.0 router(config-if)#exit router(config)#exit
@zsdc Thanks for your comments!
Thanks for quick reply! :)
Jun 21 2019
When were talking web-interface (not the api itself) it needs to have the functionality to "stage" multiple changes before commit'ing everything in one go, just like in the cli
Jun 19 2019
Jun 18 2019
this is also the case for ping 127.0.0.1 count 100 flood
Jun 5 2019
When you downloaded vyos-build did you download it or used git clone? It complains about an invalid git repository so i suppose you used the download option?
Is the vyos-builder container newly created?
What command did you use when starting the docker container? Make iso also require sudo to run but missing sudo that not generate that error message
May 31 2019
May 28 2019
May 17 2019
Hi yun, please open a new ticket with your issue, and make a reference to this case :)
Apr 25 2019
added not on old-style cfg-mode templates
Added a sidenote about switching on router and routing on switch
First commit on implementing this: https://github.com/runborg/vyatta-cfg-system/commit/15f6f2e06cc3e7d4e25f9cd381e70b8d978717f6
Apr 16 2019
@hagbard This commit adds a route to the kernel routingtable and bypassing FRR, this is no good and this would break. Please make the script add the appropiate commands to frr instead. This way frr will be in charge of populating the kernel table. Also note that this route needs to be removed on dhcp release
Apr 5 2019
That is easy.. if level admin is set, the user is propagated into the config.. if the admin don't set it, the user is not propagated, and the user will not be able to login ..
looking at this from a security perspective i would keep level admin, but block users of operator.. then any user is not automatically getting more privileges without the admin notice it….
When a host-name is not present, set the same default as on a newly installed device... router or vyos.. (atm. i don't remember what it says)
Mar 28 2019
And yea, i feel like the configuration is quite backwards in the curremt implementation... Configuration of the ppp interface should be in its own interface block, and not inside a parent interface like it is today.. the parent is only an attribute on the ppp interface...
PPP supports many forms of transfer, hense the dialer interface on cisco. almost all supported ppp/slip etc. functions are supported by the dialer function in a cisco device. Now, vyos supports PPPoE, but we don't support any other PPP "format".. if we intend to add support for more formats (serial nullmodem, modem, isdn++) then i would favor a new Dialer or Dialup interface type.. if not.. why not call it pppoe?
Mar 22 2019
Code is now merged, please test in the next rolling release tomorrow
i've updated the code to handle <, > and probably other special characters. for now its waiting a merge on current/rolling and needs testing when merged
Mar 21 2019
As i see it this is a fundamental change and should not be allowed into 1.2 LTS but it migth be added to 1.3 (just a opinion, not a decition)
Mar 17 2019
Hi rherold!
Feb 9 2019
Hi adestis, what you descripe is possible to do today with the help of a shellscript and the crontab, if you are interested i could help you create a script that does this for you, the one drawback is that the failover-time is in the ballpark of minutes, and the routes are not present in the configuration... Also, cron fills the log with messages every time it executed
Feb 2 2019
That is not how wireguard works ? that is how ipsec and openvpn works.
This is how ipv4 works :) and have nothing to do with wireguard, ipsec etc. Actually the config you have applied eill in some situations work, but that relies on the handling of the packets inside the kernel and is not following the tcp/ip principles... If you take a look on the quick start guide on the wireguard webpage you se it there aswell... https://www.wireguard.com/quickstart/.
Hi! I see that your tunnels does not resides inside the same subnet, one devise is '10.0.90.1/24' and the other one '10.0.100.1/24'.. please move one of then to ip .2 in the subnet belonging to the other router.
Jan 26 2019
Until we redesign the firewall CLI, I'm making the rules match eth0+ instead. I hope the performance impact will not be too high.
Jan 11 2019
Jan 7 2019
The fault is found in the vyos-strongswan codeset,
Dec 23 2018
Dec 17 2018
@c-po i've updated the Dockerfile and added build notes in README.md to build the vyos-strongswan module in this PR: https://github.com/vyos/vyos-build/pull/31 . please test it out
I've added a PR in vyatta-cfg-system (https://github.com/vyos/vyatta-cfg-system/pull/94)
Dec 12 2018
Sorry @hagbard this was completely forgotten from my part.
Dec 7 2018
I did a build yesterday that went trough without issues..
I was using custom kernel, wireguard module and strongswan module. So from my point of view everything is fine now.
Dec 2 2018
@syncer, this is a quite serious security issue and a deal breaker for dmvpn. As we have earlier stated that dmvpn is working now (http://blog.vyos.net/vyos-development-news-in-august-and-september) i think this needs to be fixed before 1.2LTS ... OR. We need to make a new statement that states that dmvpn will be broken in 1.2LTS..
I've been trying to get a dev environment for vyos-strongswan up and running for a couple of days now but are unable to compile it.. right now i'm stuck with the compile system not finding my libsoup-2.4 package :/
Nov 30 2018
Nov 28 2018
While it is work ongoing on this, the code for LLDPD is quite old. i would request an upgrade to the newest version . https://github.com/vincentbernat/lldpd/tree/1.0.1
Nov 25 2018
The fault is verified on the latest rc8 and the latest rolling vyos-1.2.0-rolling+201811251437-amd64.iso
Nov 24 2018
Hmm, please enligthen me. Google BBR is a new way to handle congesition instead of the traditional way tcp deals with it. This functionallity needs to be enabled in the end host systems starting the tcp session to have any impact on troughput and congestion control.. as vyos is a router and are not responsible to start tcp sessions on behalf of any end system, what is the benefit of adding this functionallity?
Another way is to check in /etc/os-release, but that is also a changeable file.... Wondering where lsb_release reads it from ( no pc atm, so cannot check)
Nov 23 2018
Nov 10 2018
Its a little hack, but not the ultimate one i think :p temporary files for storing state is used quite a few times inn the original bash/perl scripts
as noted on slack:
A way to implement the run once for tag :
If we in the tag after first execution add a temp file 'touch /tmp/complete-blah' , then we check for existance on that file on every run and skip of it exists..
in eg. wireguard/node.def:
end: if [ ! -f /tmp/runonce-wireguard.lock ]; then sudo sh -c "${vyos_conf_scripts_dir}/wireguard.py" touch /tmp/runonce-wireguard.lock fi
Whis way the wireguard.py shuld only execute on the first "execution" and be skipped on all recurring runs.
Nov 9 2018
I've been looking into how this is implemented in all instances of interfaces/* and everyone uses the same run on every tag value instance approach.
Here are a couple of examples of easy implementations looked from node.def
openvpn:
sudo /opt/vyatta/sbin/vyatta-update-ovpn.pl "$VAR(@)"
Nov 7 2018
Oct 30 2018
This is exactly the same issue i reported in T786, for every interface thats created the script runs its full processing.. when 10 interfaces are created it tries to execute it 10 times and so on. I have purposed a fix for this behaveor in T786 and there is a PR (https://github.com/vyos/vyos-1x/pull/33) on this. Another thing that could be done to fix this is to fix the underlaying vbash code that makes this happen, but i think that is a larger task.
Oct 17 2018
Ahh, my mistake! Will remember that :)
Oct 10 2018
@hagbard, the powerctrl.py script allready have everything needed, --check to check for scheduled reboot. :)
Oct 9 2018
Hmm.. i think some things is missing here... the "reboot" and "poweroff" commands is using the new /usr/libexec/vyos/op_mode/powerctrl.py script to schedule reboots, but "show reboot" and "show poweroff"
Oct 8 2018
General:
Support for multiple non-ASCII, non-Unicode encodings
- Remove it
Sep 20 2018
I've now sucessfully labbed your config, and are able to get dmvpn up and running with your ipsec config :
Sep 5 2018
Yes, in some situations this is resolvable eg in the service broadcast-relay example. Here the owner parameter could be moved to the "top-node" for that block. the problem with interfaces is that every config block is a tagNode, so we can't do that trick without moving it to the interfaces node that catches all interfaces., and not just interfaces of the type you want.
Sep 1 2018
Aug 26 2018
nize @c-po!
a new image is created to hotfix frr not starting before vyatta-router: http://dev.packages.vyos.net/tmp/vyos-1.2.0-frr-20180825.iso