I think not setting the MTU at all if the user doesn't configure it is the right way to do it. It would be nice if we could detect an interface's max MTU but I couldn't find a way to do it either (I didn't really search that hard other than looking under /sys/net/{ifname} and /proc/sys/net).
@thomas-mangin Which other dependent interfaces do you mean? All other interfaces that depend on the ethernet interface should leave the MTU untouched too, let the OS choose the defaults.

This should probably be:

if eth['mtu']:
    e.set_mtu(eth['mtu'])

Then if the user doesn't set a mtu, we don't try to change it. If the config set mtu is wrong the commit should fail, but it should get verified in the verify section by a max mtu read from the interface (if that's possible), or leaving it as it is now. It shouldn't silently (or even loudly) continue as that would make the failure undetectable at boot.

Scratch the above comment - I'll write a simple utility function that parses the STP config from the bridge, and some utility functions to remove duplication for adding the bridge members and setting STP on them, that should be good enough.

This isn't as important as I thought initially as the interface scripts verify function will prevent adding interfaces with addresses to a bridge or bond - thus a simple 'ip addr flush dev x' will suffice to flush the remaining (should be just the fe80 link-local), as there should be no dhclients running.

On a dual-core Pentium E5300: 2.2s, time for completion 5s.

vyos@rt-home# time /usr/libexec/vyos/completion/list_interfaces.py --help
usage: list_interfaces.py [-h] [-t TYPE | -b | -br | -bo]

It takes 2s even with just --help. I can't explain why it takes 2s by itself, but the completion takes 4s. 2s must be added elsewhere.

vyos@vyos# time /usr/libexec/vyos/completion/list_interfaces.py --help
usage: list_interfaces.py [-h] [-t TYPE | -b | -br | -bo]

https://github.com/vyos/vyos-1x/pull/388

@robertoberto issue (cannot change udp fragmentation-offload) is not the same as the original post (changing MTU out of range) so please create a separate task for it.

We must be able to call klass('eth0.1.2', create=False).add_addr to add an address on the vif-c and also klass('eth0.1', create=False).add_addrto add an address on the vif-s. I'm adding functions on Interfaces class to purge/restore addresses which will be used when adding/removing bridge/bond members, T2367.

https://github.com/vyos/vyos-1x/pull/384 is the initial fix for this.

A list of all related tasks from a search: T1999 T1877 T538 T970 T99 T1095

Right. In my opinion it would be necessary to change that.

I found that it was due to set_vrf which uses the same master/nomaster commands that bridge uses. I'm adding checks and conditions to all interfaces to prevent that - raise ConfigError if both are set, and only set_vrf if vrf is set. The prior idea I had with re-adding the interface to the bridge at the end isn't necessary in this case, but for other interface types, where the interface itself is deleted and recreated, re-adding it is still necessary. The PR should be ready for initial review tomorrow.

Wrong location of status file - it was moved to /run/openvpn

They're still broken here. Maybe a different bug. It would be nice to switch to 'status-version' 2 or 3 too for more info.

vyos@rt-home:~$ show openvpn server

That's unfortunate. I get that we need vyos.ifconfig to abstract interface management, but I thought pyroute2 could at least be used to replace all the calls to 'ip'. I guess that's not the case. I searched for pyroute2 and I see you already tried it, so I'm closing this.

If in crux this was just a option string passed to the openvpn process,
quoting or escaping could be used to pass a parameter with '--' to an
openvpn option. I need to have a good long look at how Crux did this and
have some real life examples. For example: openvpn-option '--mssfix --up
"/some/command --param1 --param2"' (I'm not sure if this would've worked
on Crux, the quoting is probably wrong, and the up option parameter too,
but my point remains that this could've been a valid option syntax)

Crux probably passed this as a string of options to the command line or
split it into multiple options. We need to add a parser to split the
options by '--', hopefully this won't break any options which should
include -- in one line.

I'll try out the latest code then. But on 0421 with vyos-1x from 04-23
15:11 the issue is still there. I had most of the fix ready, it re-added
the interface back to the bridge it is supposed to be in after applying
all settings. I've thought about if this could be some function/method of
ifconfig, but I don't think it's necessary or how it would be
implemented. If the issue is still there, I'll open a PR. Then if there
is a bigger need to add this to ifconfig you can do it later.

Do they appear in the journal? sudo journalctl -f
I think logs go to systemd-journald first, then are forwarded to rsyslog,
which logs them to files. I've said some time ago, ever since 1.2 moved
to Buster and journald came in, that we should move more to native
journald logging away from rsyslog. I enable persistent journal storage
in /etc/systemd/journald.conf after every upgrade just because of this,
the rsyslog config is buggy/broken, it doesn't log half of what it
should, it stays in journald, so I just use journalctl to look at all
logs. I don't know if journald supports logging to separate files like
rsyslog though, by default it uses its own binary format, I think that
can be changed and maybe rsyslog file behavior moved to journald.

If this happens to you, you don't need to delete and re-add the members in the config, you can run sudo ip link set dev ethX master brX to add the eth interfaces back to the bridge.

660 is not enough as the created file is already 660 root:root, which
means just root has the rights to write to it. The failing script isn't
run as root while in a config session (validate-value.py). I'm not
exactly sure which user (vyos or vyattacfg), but as this is a debug log,
it's not security critical and can be set to 666. Otherwise it'd need to
be owned by a group into which all the writing users must be put into,
and can stay 660.

All that's needed is to chmod 666 the file after creation - I did that
after I found the error and all scripts could write to it fine.

Please test with a image built after April 23 20:44 (no image is built yet, the next one should have the fix for T2362 included)

Fixed by T2362

In T2366#61424, @runar wrote:

"This is fine if used in conf_mode scripts that'll create it after that anyway" if the intention of the code was not to create the interdace this is not fine if you ask me. :)

is if iface in Section.interfaces() the correct way to check if the interface already exists?

Actually, if an interface doesn't exist and if we try to get its properties (for example if mac != BridgeIf('br0', create=False).get_mac():) that raises an exception. I'm not sure what the best way to do here is. Use create=True anyway? This is fine if used in conf_mode scripts that'll create it after that anyway, but what if we're checking another interface that we don't know if it exists or not? First do an existence check? How do we do that?

Bug: if I create '/config/vyos.log.debug' with contents '/config/vyos.debug.log', /config/vyos.debug.log is created as root:root rw-rw-r--, and later scripts that use call() but aren't root, don't have the permission to write to it, and fail. For example any validator like mac-address fails as if the value is invalid, but if we turn on its debug flag, we see the real error is [Errno 13]: Permission denied: '/config/vyos.debug.log' because 'src/helpers/validate-value.py' uses call(), but it isn't ran with root privileges. The debug log should be probably created with 666 permissions or its group changed so that all scripts, even non-root, can write to it.

Oh, I see what that's supposed to do - if there was a 'mac' set to change the interface's mac address, it sets that back to the real factory mac. In that case, that's fine (it's done every time if no 'mac' node is there, which is rather pointless, but shouldn't harm anything), the bug with interface renaming is a separate bug that's not applicable here.

@c-po looking at your commit d80398b6, I don't think that's how the hw-id node was supposed to be used. It was never used as a way to change the interface's mac address, rather it was used to rename the interface with the matching mac address to the name it has in config.boot. This is done by some vyatta scripts at boot time. If we later set the same mac on the interface that it should already have (as it was renamed by the vyatta scripts), that's pretty pointless to do IMO.

Looks good. Is detect_if_systemipv6_is_disabled() already a
system function? If so, It can be incorporated (by you if you wish, or by
me). The last line is missing += by the way.

There are places in the code where operational commands are still ran without create=False, for example:
https://github.com/vyos/vyos-1x/blob/675f400bacb03ae93be928e7270f89205d1036b9/src/conf_mode/interfaces-bonding.py#L242

The above PR is tested to fix this issue and T2345.

https://github.com/vyos/vyos-1x/pull/371

Ah, I figured it out - the contents of vyos.log.debug are used as the path to the logfile, if empty (but present) the default /tmp/developer-log will be used, otherwise no logfile will be written. But I think I've hit a bug - if multiple 'flag' are set (other than 'log') the system hangs during boot.

My fix for that was merged 7 hours ago so your 202004210117 image doesn't contain it. https://github.com/vyos/vyos-1x/commit/c7d8e39be10a59d64be643cade2213c97f1e3639

https://github.com/vyos/vyos-1x/pull/364

I'm working on T2345, but the root issues probably aren't the same. Do you have service router-advert configured, and is it on a bridged interface? Then the cause is T2345. If not (if you have router-advert and dhcpv6-server on a eth interface) then this is a different issue.

This is due to the bridge missing a link-local address. The bridge members also don't need link-local addresses (currently they have them) and IPv6 can be disabled entirely on them.

This is a pretty serious bug. Is there any progress?

https://github.com/vyos/vyos-1x/pull/363

@c-po can you please test if this now works, if so the task can be closed. My testing showed that it does.

https://github.com/vyos/vyos-1x/pull/361

Yeah, I missed that one. Thanks for fixing it c-po.

Tested latest rolling, hw-id works as expected again (albeit sometimes buggy, but that's nothing new).

Caused by T2273, issue is also in T2308: systemd uses a private /tmp dir. Should be moved to /run/openvpn or the systemd-private dir disabled (I prefer the 1st option)

I can take this on in conjunction with T1499 since there has been no activity on it for a long time and the issue still very much exists.

@c-po this is the commit that caused this issue. You renamed the config node but didn't include a migrator. https://github.com/vyos/vyos-1x/commit/021a2470bd67dccfac0a53c9f4ef511640c03101

I'll take this one.

I spent the last hour at the console trying to fix this mess. It left me with completely broken internet and also bridged the WAN and one of the LAN ports (several of which are in a bridge). I must've tried rebooting 10 times with both 202004191028 and 202004141515 until I could finally get things to work properly with 202004120117. Before this, I've had problems with 1.2 and 1.3 rolling for years where sometimes the interfaces would get mixed up, but usually one reboot fixed it. Now there is a 100% chance of them being completely mixed up every time.

OpenVPN was migrated to a systemd service with auto restart so it's possible it could have fixed this issue. Please retest with latest rolling.

The recent work on openvpn added net30 as an option for "server topology" and marked it as default in the shell value help so at least users should now know it's the default. Personally I'd like the default topology to be subnet but that would mean adding a migrator script for old users who use net30.
It also rewrote some parts of the ifconfig setting logic. This should be retested if it's still an issue.

So if we wanted to not use compat-names because of T2113 the client node names would need to have spaces, I don't know how the config system would handle this? It could probably take a quoted value as the client node, but I'm not sure the shell completion would handle this - it already has problems autocompleting quoted values (for example if you try tab-completing a description with a space in it, you'll see what I mean). Shell completion would very likely break with quoted node names. A workaround could be to remap underscores in the config client node names to spaces for the actual ccd file names. I don't quote like that option, but the alternative would be to have to fix the shell autocompletion for quoted values (better in the big picture but more complex and time consuming), or not fix T2113.

https://github.com/vyos/vyos-1x/pull/342 should add IPv6 support for all use cases (server, listening socket, p2p, client).

The script now prints a warning on commit if the server client IP is in the pool. There is a new config node for setting the pool start/stop/netmask/disable, if not set, the defaults of openvpn are used.