https://www.syslinux.org/wiki/index.php?title=Isohybrid

This will be a killer feature. I wanted to spin a Atom C3000 board with VyOS 1.2 but that board comes with UEFI only so right now, no VyOS on this one. Debian Jessie CD on the other hand boots fine (build with UEFI support)

VyOS 1.3 is fine for me

What happens on Hypervisors not supporting UEFI or older Hardware Platforms without UEFI?

I think we should take care about this in the VRRP scripts and leave the base system untouched. Meaning, take your proposal and remove

update_sysctl_conf net.ipv4.conf.default.arp_filter 1 \
    "reset promiscous arp response"

@rps seems to be the case. sorry for the noise

arp_proxy setting was introduced in an ancient commit https://github.com/vyos/vyatta-cfg-system/commit/496526b572ca83308a858b2ec4771d2f05f4970c

@dmbaturin I actually comitted the fix yesterday morning. Somehow Phabricator only shows the corresponding commits when logged in.

Please find some older rolling releases here:

As requested by @runar:

See https://phabricator.vyos.net/rVYOSONEX0ac5a4f94a8a4e84ed73c2288bcb9a4c77b9b695

Invalid SNMP addresses must be filtered, else the service won't start with this error message:

Sep 16 20:32:58 LR1 snmpd[4848]: Error opening specified endpoint "udp:192.168.1.1:161"
Sep 16 20:32:58 LR1 snmpd[4848]: Server Exiting with code 1
Sep 16 20:32:58 LR1 snmpd[4845]: Starting SNMP services::
Sep 16 20:32:58 LR1 systemd[1]: snmpd.service: control process exited, code=exited status=1
Sep 16 20:32:58 LR1 systemd[1]: Failed to start LSB: SNMP agents.
Sep 16 20:32:58 LR1 systemd[1]: Unit snmpd.service entered failed state.

I can confirm L2TP/IPSec working with Windows 10 (1803) and Apple iOS 11.4.1 together with RADIUS auth backend.

VyOS Kernel was rebuild with retpoline enabled https://phabricator.vyos.net/T819. As Kernel modules sometimes depend heavily on the unterlaying ABI (Application Binary Interface) this will break if the module is not rebuild.

In addition the old patches from https://phabricator.vyos.net/T17 have been re-applied to the net-snmp repository b/c they were lost in translation on the move to Debian Jessie.

This is whats happening when we add L2TP/vpn configurtion and do a commit:

Fixed by installing dependency.

There you go: http://www.mybll.net/vyos-1.2.0-rolling+201808230337-amd64.iso

After a successfull connection I see the spawned process:

root      2595  0.0  0.0   4332   124 pts/1    Ss+  22:58   0:00 /usr/sbin/xl2tpd
root      2868  0.5  0.2  26108  2484 pts/1    S+   22:59   0:00  \_ /usr/sbin/pppd passive nodetach 10.255.255.0:172.16.222.1 refuse-pap auth name VyattaL2TPServer debug file /etc/ppp/options.xl2tpd /dev/pts/1

Okay, I narrowed it down even further:

Thanks! Sounds like a proper fix to me.

I‘m using VyOS 1.2.x wirh a 4GB HDD on ESXi

Issue was introduced between those two images:

I guess then it was "broken" all the time

Does downstreaming work when you configure set system ntp allow-clients address?

@dmbaturin the "workaround" and implementation is IMHO super bad (https://github.com/vyos/vyos-1x/blob/current/src/conf_mode/snmp.py#L808-L813) as it uses /opt/vyatta/sbin/my_set or /opt/vyatta/sbin/my_delete.

Yes, just pass the variable on calls to os.system()

Even happens without any argument:

cpo@LR1# sudo /usr/sbin/lldpd -d
2018-09-01T20:12:53 [WARN/lldpctl] unknown command from argument 1: `#`
2018-09-01T20:12:53 [WARN/lldpctl] unknown command from argument 1: `#`

Happens too when started by hand, where 172.16.254.35 is the management address

The user/password thing is closed. The Port issue seems to not be easy. Will be easier with a vyos-1x rewrite

IPv6 DHCP

Just tried your configuration and adopted it to my LAB. I can't reproduce your issue.

Done!

Done https://github.com/vyos/pmacct/commit/22b9be62d8e1eba71db8391fe86ad95181645887

I had the exact same problem for the service broadcast-relay code. I did a cleanup on the youthful folly. Resulting in this issue going away (https://github.com/vyos/vyos-1x/commit/fd1eabe72862ec364643a61cb94b21c330a385f5#diff-e27a1d5bf8f371aae9da8bbd36e674d0).