I reproduce the same problem on VyOS 1.1.8 on different region - N.Verginia.

@dmbaturin can you confirm an issue?
i move that to 1.1.9 backlog

Thanks for discussion, marking this as wontfix.

Does anyone have any ideas how to get VRRPv3 in 1.2?
If we could conclude on the approach we could go further by describing cli commands, make out how the upgrade should be done, create documentation and so on.

You're spot on and I realize how naive my original request was. Pi-Hole isn't something that should be running on an edge device.

Meanwhile I learned how to successfully use DFS with the ATH10K driver. It is kind of a nasty driver to use as the makers put many obstacles into firmware and the driver module code to prevent "daisy chained" accidents related to setting wrong regulatory domains. RegDomain setting was not possible without Kernel config parameters "CONFIG_ATH_REG_DYNAMIC_USER_CERT_TESTING" and "CONFIG_ATH_REG_DYNAMIC_USER_REG_HINTS". I guess that was the reason why hostapd always crashed when trying to use DFS.

Sorry for the unsolicited feedback, but... BUT... ;-) Honestly, I think the way the Pi-Hole stack is put together does not lend itself well to a firmware-like platform like VyOS. In fact, personally I can't even suggest it for anything more than home use. Frankly, it's a bit cludgy on the back-end. Further, it increases the potential attack surface of your router, which is in general bad security practice. IMO the best course, even if by some twist of fate Pi-Hole WAS integrated into VyOS, would be to run Pi-Hole as a separate service. DNS is one of those things that's easy to run alongside routers; there's no compelling reason I can think of to run it ON the router. Buy a $35 Pi, run a tiny VM on existing hardware, etc. and serve that DNS server to DHCP clients via VyOS. That's my $0.02, adjusted for inflation.

support added,
only need Jenkis up to build te kernel.
https://github.com/vyos/vyos-kernel/commit/b72a65de9fd1c68c8d371152cfdcbc85d2b0dbd9

@ebob9 Thank you! It's very helpful.

Played with the VHD and attempted to make it an image that could be deployed as a template. Looks like the following is lacking currently to allow provision support:

• No support for provision credentials (that's ok for me)
• WAAGENT can't ever report provision success to azure.

Probably not the best place to ask, but can anyone guide me the steps to build VyOS 1.2 with frr. I have built the latest source but it still comes with quagga (and without IS-IS support which is enabled in 1.2 alpha image).

But should it be configurable using cli?
Should there be a warning when adding a interface and no buffer is available?
Should there be some smartness created for avoiding the "no buffer" event?

Since that wasn't included in 1.1.8 for some reason
reopen

Anyone having any ideas to how to solve this problem?

Unfortunately this does not properly work as debian live-build can not distinguish between ISO and IMAGE because both are actually the same.

@dmbaturin do you know what is for?

Worked, thanks
https://wiki.vyos.net/wiki/User_Guide#mDNS_Repeater

After removal of telnet configuration nodes/scripts and upgrading from VyOS 1.1.8 with telnet enabled worked.

Installing VyOS 1.1.8 on RAID1 and later on upgrading to 1.2.x works. Also the RAID set is intact.

vyos@vyos:~$ cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sda1[0] sdb1[1]
      4190144 blocks [2/2] [UU]

whitelisted again,
buggy system, try in 10 mins or so
hopefully will work this time

Still the same

try again please

I wanted to add the following into the WiKi

TODO: Add CI job for https://github.com/vyos/mdns-repeater when CI is back online

Using AVAHI as mDNS reflector has the big disadvantage that the reflection interface can not be specified. It will reflect the mDNS messages on ALL interfaces. Mdns-reflector does not have this problem. It needs to be configured which interface is used for repetition. Configuration is planned for vyos-1x package.

This change seems to have found its way into current somewhere between 999.201711072137 and 999.201711160506

https://github.com/zevlag/pfsense-ports/tree/master/pfSense-pkg-zerotier
https://docs.opnsense.org/manual/how-tos/zerotier.html

After a lot of reinstallation and terminaton we broke Amazon VPS, so I did full test.

@begetan Does creating it with one interface first work for you?
Also, I still need the show version output from the running instance (complete with S/N and UUID) to see if it's the same issue or a different one.

I've did a lot of attempts, and removed old stuff. Anyway I can reproduce it one more time with the same result.
I am configuring 2 interfaces for the virtual router. May be it can be a problem?

@begetan It is the same build that the marketplace team at AWS distributes to all regions. I've just made an instance in Frankfurt and it worked for me.

I face this issue on the new VyOS 1.1.8 AMI in the Frakfurt region. It is working in Seoul region.

Is this really an issue with 1.2? It looks like FRR 2.0 is what vyos-frr is based on and FRR 2.0 appears to have support for BGP AddPath.

After some discussion surrounding similar issue in IRC recently, I believe FORWARD is the correct place for this, and 'set-mss' should be configurable in a rule which can specify one or both of input *and* output interface to allow proper expression of explicit MSS for inbound and outbound connections.

trivial patch

Ah ok, maybe that not the case than

Each time a new image is added via add system image GRUB configuration is triggered.

i mean, if that works silently but after install fails to boot from SW RAID
assuming that part of raid installs affected

@syncer what do you mean by "other installs"?

i think we also need mechanism to fix other installs once we sort out this problem

Here it is

Rebooting the router fixed it...

I appreciate your work! Could you make the patch easier for us to merge and then to track for release and changelog?
Here's the proper procedure for making patches: https://wiki.vyos.net/wiki/Submit_a_patch

At a glance, a lot more looks wrong here than just this. Why is it checking for every rule in the rule set if the rule set is uniquely named?

Backporting coreutils could give us quiet some headache ... let's just schedule this for VyOS 1.3 where it will be auto fixed.

@alainlamar thanks for detailed description!
I wish that all tasks were created in that way.

Thanks!
Marking this as solved

Implemented as 10 second timeout in https://github.com/vyos/vyos-build/pull/14