Implemented in latest rolling and backported to Crux branch for 1.2.1

An easier solution is to wrap the test in ' like use-web='this is your IP'

After some digging this is what I found out with VyOS 1.2.0-epa3:

Handled in/with T484, hopefully

Please retest with a new rolling release tomorrow

Patch does not apply cleanly, need to backport it but will do

Yes

So this problem still exists but I have no clue where to add it in our source @dmbaturin @UnicronNL

Ah, there was a similar issue with dhcp last couple of weeks where quotes broke the config (T1129). Can you try using &nbsp instead of your whitespace?

Con you provide a configuration to reproduce the issue?

I can confirm this. 1.2.0-EPA3 does not have thisbissue but 1.2.0 has it.

Package needs to be build from source. There are already some packages which we build that way like libyang or librtr so not a big deal.

Sounds more reasonable (enable than disable). Will this affect backwards compatibility or will there be a migrator?

@danhusan is this your expected behavior?

can you share your DHCP configuration with us for reproducibility?

IMHO this is a general CLI design issue.

Nope, I used:

@hagbard I replaced vyos user with another one. Also image corporate setups where RADIUS is used for authing and there are no local users.

There are no disadvantages in doing so. Any contribution is welcome.

Depending on the task which needs to be executed a script might need to be run as root.

lsmod output from 4.18.6-1 (all 4 NICs working) please. We already have a lsmod output of the other versions.

Please place your code snippets inside a Code section as mentioned above, this makes it easier to read.

No reply from the vendor so far

Latest is fine

No issue known but it eases reproducibility

@alexandrestein can you share your complete dns forwarding config node please?

The provides Dockerfile lists all packages which are needed to compile VyOS on a Debian jessie host. If you do not want ro install all this on your host simply use the provided Docker image and you are ready to go.

Thanks. An lsmod from rc5 would be nice, too.

Can you share the dmesg output from RC5 please?

It also reports:

ISO is still building. You are right, a NIC is a NIC, but a NIC consists of a MAC and a PHY which does the PHYsical interface. you can have the same MAC part multiple times but with different PHY ICs. Lets wait for the ISO to compile.

According to the datasheet https://f.ipc2u.de/files/add/doc/445/3I380D-D90-Datasheet.pdf I see no PHY that is used on this board - nevertheless I saw that we do not ship every avialable PHY driver, also drivers present in 1.2.0-rc6 are no longer present like CONFIG_BCM7XXX_PHY. I will provide you with an updated ISO for testing.

Looks like a general issue here. Do you still have the old Buster ISO with Kernel 4.18 that you can install on the target HW?

• (K)ASLR is enabled with https://github.com/vyos/vyos-kernel/blob/35c51d3b30f29110aab12ade5f11f928c68951ec/arch/x86/configs/x86_64_vyos_defconfig#L405
• DEP

vyos@vyos:~$ show system kernel-messages | grep "Execute Disable" 
NX (Execute Disable) protection: active

• RELRO there's some info in the Debian Wiki but it reports permission denied: https://wiki.debian.org/Hardening

@rps what about changing the minimum supported MTU from "68" to "1450" which is the default that is used in VyOS.

Thanks for your contribution. It will be included in the next EPA and rolling images.

I will approach the vendor first.

@SteveP as it works with Debian Buster it should work with our newer Kernel, too.

Anyone can provide me with a hardware?

@dongjunbo same hardware?

Where to get those MIBs? should be simply to test before adding it to the iso