I have adjust the logic which now sets the interface MAC address before any other parameter. Using the OSI model this makes sense as the MAC layer is below IP.

I can now again bridge the WIFI interface to br0, please resolve the outstanding commit message changes and then it feels good to me! Thanks

In T3067#80025, @jack9603301 wrote:

# Bridge port handling of wireless interfaces is done by hostapd.
        if 'wlan' in interface:
            return

Why can't wlan be completed in bridge.py?

Why not use ERSPAN?

Resolved as informed by @tuxnet

Ungortunately this is a -1 from me.

This will be resolved / migrated away in T3048.

We have a basic implementation available. Additional changes should be submitted via feature requests.

VyOS 1.2 adds a random link-local address on tunnel interfaces by default.

In the specified timerange

Next rolling release will carry the revert

Thank you for the feedback! Will incorporate this into the rolling releases. Looks like once again Intel did us a favor.

I have reverted the commit of QAT driver update. can you please try out this image:

@ernstjo yeah we also have this "situation" with wireguard tunnels. Should be fixed in general with the rewrite of tunnel to get_config_dict() which is the second last interface not using this scheme, vti is last.

Usually all of them have a serial failback thus they should work, currently there is only a smakk subset of vyos verified LTE modules as each and every modules comes with its own problems:

Docuemntation from: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/performance_tuning_guide/sect-red_hat_enterprise_linux-performance_tuning_guide-tool_reference-tuned_adm

@lucasec of course this commit could be related and we can try revert back to the old version. Would you be willing in testing a binary for us?

as we rely on OpenNHRP this looks like a dead end as of now. Maybe IPv6 support will get introduced and supported when we can migrate to FRR based NHRP - there is another task about that (T2326).

Your referenced commit is only relevant for validation logic if your hardware supports QAT or not. We now run Kernel 4.19.155 - please retry with the latest rolling release.

@tuxnet maybe this will help: https://docs.vyos.io/en/latest/routing/multicast.html

set interfaces ethernet eth2 dhcp-options no-default-route

Available via set interfaces ethernet eth0 dhcp-options host-name