this solve the issue

http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyatta-wanloadbalance/vyatta-wanloadbalance_0.13.70+vyos2+current1_amd64.deb
solving the issue
it may be closed

@hagbardIt fixes the issue with WANLOADBALANCE_PRE chain, but we still observe unexpected behavior.
I will write a little bit more letter.

/var/log/messages

Brill, i've applied that patch and will keep an eye on it for a few days to see what happens.

can you edit /usr/libexec/vyos/system/on-dhcp-event.sh

The line giving the error is:

@TriJetScud please see :

I think we have a much fresher strongman,
maybe someone picks it up to rewrite in python

To be fair, the things we're need to make this work is

@thinkl33t can you please also provide a "faulty" /etc/hosts file?

Oy. Turns out that other routers (like those that found in ISP-provided cable modems) can have subtle quirks in their DHCPv6-PD implementations. I've worked around another one.

Should be in the latest rolling or here: http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyos-1x/vyos-1x_1.2.0-13_all.deb

@hagbard is the patch for the validator issue in latest rolling or do you have a .deb i can apply ? :)

The client status file information is quite different compared to the one from a server config, I couldn't find a way yet to retrieve the information for the table.

@zsdc Is it working for you with the package above?

@zsdc All right, http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyatta-wanloadbalance/vyatta-wanloadbalance_0.13.70+vyos2+current1_amd64.deb should solve the issue you are seeing. The code of the binary is good for another dozen bug tickets =)
Pls let me know if it works as expected, since I only tested your particular use case.

LBDecision::execute(): applying command to system: iptables -t mangle -A WANLOADBALANCE_PRE -i eth1 --proto all --destination ! 192.168.0.0/16 -m state --state NEW -j ISP_eth1
Bad argument `192.168.0.0/16'
Try `iptables -h' or 'iptables --help' for more information.
LBDecision::execute(): applying command to system: iptables -t mangle -A WANLOADBALANCE_PRE -i eth1 --proto all --destination ! 192.168.0.0/16 -j CONNMARK --restore-mark
Bad argument `192.168.0.0/16'
Try `iptables -h' or 'iptables --help' for more information.

Happens in /opt/vyatta/sbin/wan_lb.

Thanks for testing. New rolling has been built as well.
https://downloads.vyos.io/rolling/current/amd64/vyos-1.2.0-rolling%2B201902142225-amd64.iso

With new package all works fine.

I checked the 'server' options for 'push-route' and 'name-server' and even with these configured as opposed to the openvpn-option configuration entry, it still gives the "Options error" complaint about the push command.

The last rolling worked great. Saw the module was loaded on boot and MSS was clamped correctly.
Thanks!

Please test http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyatta-wanloadbalance/vyatta-wanloadbalance_0.13.69+vyos2+current1_amd64.deb or latest rolling release.

@kroy by using chroot and trying to install the vyatta-cfg-quagga package i found out what is causing my build iso error:

@Maltahl just re-tested this, with the staticd=yes added, and a reboot done.
When i add two static routes i would expect the /24 route to work because it is more specific. But is does not and show ip route shows only the /23 blackhole.

@Maltahl for me it was not fixed with that addition, and i read above that others had this as well.

i tried doing complete reinstalls and i can now confirm this bug as well.

Thank you!
I'll test the next rolling asap and report back.

Latest rolling should autoload the module

Need to reopen this task.
Version: 1.2.0-LTS.
Running configuration:

vyos@test-01# show 
 interfaces {
     ethernet eth0 {
         address 192.168.55.18/30
         duplex auto
         hw-id 08:00:27:95:bb:f6
         smp-affinity auto
         speed auto
     }
     ethernet eth1 {
         address 192.168.56.3/24
         duplex auto
         hw-id 08:00:27:8e:d6:fb
         smp-affinity auto
         speed auto
     }
     ethernet eth2 {
         duplex auto
         hw-id 08:00:27:8c:27:04
         smp-affinity auto
         speed auto
     }
     loopback lo {
     }
 }
 service {
     ssh {
     }
 }
 system {
     config-management {
         commit-revisions 100
     }
     console {
         device ttyS0 {
             speed 9600
         }
     }
     host-name test-01
     login {
         user vyos {
             authentication {
                 encrypted-password $6$7X4XbQJ2xVMZ8$NmISPmyC1f88cIfcKig01pkjePNTVeeWwULrHgich6wB0A1TH/b31Jywpsde8Mv4/B8Qa5CxFM.rlXmfOQT0Z0
                 plaintext-password ""
             }
             level admin
         }
     }
     name-server 1.1.1.1
     ntp {
         server 0.pool.ntp.org {
         }
         server 1.pool.ntp.org {
         }
         server 2.pool.ntp.org {
         }
     }
     syslog {
         global {
             facility all {
                 level info
             }
             facility protocols {
                 level debug
             }
         }
     }
     time-zone UTC
 }

Yes! That's what i need.
In my script above i had to put modprobe br_netfilter so it loads on system boot.

modprobe br_netfilter
iptables -t mangle -I POSTROUTING -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1400

If we could have br_netfilter loaded on boot in the image that would be great and would fix this problem.

br_netfilter should already be compuled as a module. Can you sudo modprobe br_netfilter? To see if it fits your purpose? If so we can autoload it on system bootup

@thinkl33t Please test the latest rolling which has openvpn2.4 installed.

Sorry i'm not sure we're on the same page.

Daniil, Yuriy, plz watch on it, may be you got any ideas?

Vladislav thinks that the bug is not in Zabbix. On the one hand, I agree with him, because early (on early version of VyOS 1.2 at summer, autumn) it works perfectly...
But test app that he made for me works ok, without crashes... So i dont know what to do... Any ideas?

Strange. I’ve seen that error a lot. Every time it’s been when I’ve forgotten to checkout current after cloning the repo.

I checked and $ show system kernel-messages | grep pppoe0 did not return any output.

A quick progress update: I have fixed a bug (that may or may not have been present before) that prevented renew dhcpv6 interface eth3 (or whatever interface) from working outside of an active configuration session. I imagine most uses of dhcp lease renewal would occur in a normal router login session.

@kroy everything is at current, except 'frr' because then i get 7.1dev and i would like 6.0.2 to test if this solved it.
I used debian/master branch from FRR.

This will be part of a bigger workpackage when the whole firewalling is rewritten. There is yet no ETA.

@c-po thanks for mentioning the PPPoE connection, really got me thinking about the word POSTROUTING!
The solution is this -

In T1245#32694, @c-po wrote:

Your second command does kot specify any output interface whereas the first command speciefies tun0. Especially on ESXi you see almost no difference compared ro a vietual Box.

I myself run 1.2.0 in both a Physical and ESXi instance on PPPoE and use the clamping commands successfully on both nodes

Your second command does kot specify any output interface whereas the first command speciefies tun0. Especially on ESXi you see almost no difference compared ro a vietual Box.

@Merijn make sure you git checkout currenton everything.

I am experiencing the same issues with a router i tested with 1.2.0 current.
Can we create a test release going back to FRR 6.0.2?

dpkg -l | grep conntrackd

ii conntrackd 1:1.4.2-2+vyos2+current1 amd64 Connection tracking daemon

Found the wishlist priority.

I am affected too by this issue.

for example it crashing when in config from server there is a discovery rule with network like 192.168.1.0/24, early, before we patched it and remove gethostbyaddr conversion, it crashes when agent connects to it...
So it's look like all depend from ip addresses and may be gethostbyaddr....

Maybe if hostname is empty, we can prepend the mac address to the fqdn which will be stored in /etc/hosts

Something seems to be totally off with set system domain-name and set system domain-search domain

Nope. The function gethostbyaddr() is a libc function. What you can do is to try to reproduce the issue under debian 8 (jessie).
The crash in the zabbix ticket however is that the zabbix proxy is crashing when it received 3123 byte from 10.255.0.1.

Ok, so that issue has been corrected, I used the wrong validator. (https://github.com/vyos/vyos-1x/commit/1842fc9fdbcfa877e42714eaf620dff18ff9859c)

Hmm, that (the IP validation) was a different change which was working. I'll have a look.

Could it be connected? https://phabricator.vyos.net/T1214

In T1226#32490, @hagbard wrote:

All right, let me know if you need help.

Just to add extra info to this ticket, I had a openvpn-option that i wanted to add but it contained a single quote. I was not able to do this (in version 1.8.x this worked).

I was not able to test sooner. But i confirmed it works properly with rolling release vyos-1.2.0-rolling+201902060337-amd64.

1.2-RC5 already supports this (and I assume newer but I can't test it with my motherboard for other reasons-T1066). I am with BT (UK) and it works great (see my config below). RC5 does however still contain T1065 which is related to this but has been fixed in a later release candidate (RC11 I think).

 ethernet eth3 {
     address 192.168.5.1/24
     duplex auto
     mtu 1508
     pppoe 0 {
         default-route auto
         mtu 1500
         name-server none
         password xxxxxxxxx
         user-id [email protected]
     }
     smp-affinity auto
[edit]
# set interfaces ethernet eth3 pppoe 0 mtu
Possible completions:
   <68-1500>    Maximum Transmission Unit (MTU) in bytes
   1500

I will have to re-test tonight (when nobody else is using the Internet) and get some log output.

Well, I've been developing it against the 1.2.0 branch. It might work back-ported to 1.1.8, but that's not my focus.

Interface name is ppp0 but will later be renamed to pppoe0