the error in the test-log is just the errorcode, but the real error message is a memory allocation error:

vyos_bld@dd27213bf7b5:/vyos/ipaddrcheck/src$ ./ipaddrcheck
Error: could not allocate memory!

The same build procedure is tested fine on x86_64 and armhf without this issue

As a workaround could this be added as the first lines of the bash script?
This will check the primary group the script executes via and respawn as the vyattacfg group if it's something else before continuing.

if [ $(id -gn) != vyattacfg ]; then
    exec sg vyattacfg "$0 $*"
fi

NB! the if is necessary because the script should not execute the exec when you respawn as correct group.
You will end in a exec loop if its not there .. :)
i've not tested this on vyos, but have helped me on other systems

i agree with allowing this.

improvement suggestion:

• remove the use of + in hash-policy names. layer2+3 and layer3+4. this could be replaced with the more used - character, so layer2-3 and layer3-4
• also add support for encap2-3 and encap3-4hash-policy

It is true that you need a hash-policy, but specifying a hash-policy is optional, if you don't specify it reverts to the kernel default that is layer2..
also defaults should not be listed in the configuration. (because then the configuration will be crowded with all kind of strange things that is a default)

Improvement suggestion:
set interfaces bonding bond0 hash-policy # defaults to layer2, listing layer2 as an configureable alternative is then redundant. to revert to level2 the user should delete the config entry instead. also update description about using layer2 as a default

Full console dump to reproduce with comments:

##
## Start without anything

the current only way to get the interface added to the group is to remove and readd it to the group.

vyos@vyos# brctl show
bridge name	bridge id		STP enabled	interfaces
br1		8000.525405123456	yes		eth0.1

i've updated the description. the bridge is created and comitted prior to the creation of the interface.

@UnicronNL , no need to apply the patch, it is already applied to the codebase. this issue needs to be something else

@UnicronNL could you apply my patch to the codebase?

I've also tested this on the newly released dune1.11.1 with the same result

Maybe you could comment on this @zx2c4 ?

A note when stating to convert physical interfaces.

Please keep this in mind when rewriting dummy/loopback interfaces: https://phabricator.vyos.net/T1467

Thanks :) i see the pull message is updated, but could you also update the commit message to reflect this?

Hi! Thanks for the contribution!

This sounds like a good improvement!

Is this still an issue?

Most of these files are autogenerated and dont need to be saved across reboots.. is it possible to make them in a overlay that does not save to disk? Or another aproach is to just delete them when the device starts (before or when vyatta starts)

This is a good start! The names should be made pythonic and why not use getters and setters? Then we dont need set_ functions but use the objects directly.

This also affect manually built iso's that also fails because of pdns-recursor

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.

As long as its allowed but not working its a bug.. :)

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.

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

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)

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..

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

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! :)

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

this is also the case for ping 127.0.0.1 count 100 flood

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

Hi yun, please open a new ticket with your issue, and make a reference to this case :)

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

@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

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)

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?

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

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)

Hi rherold!

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

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.

Until we redesign the firewall CLI, I'm making the rules match eth0+ instead. I hope the performance impact will not be too high.

The fault is found in the vyos-strongswan codeset,

@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