The run code could check the command name against a list of known "need sudo" commands and prepend it automagically so the command looks like normal but is auto-sudo'ed

https://github.com/joejulian/xterm/blob/master/resize.c Not complicated to port in the vyos library, replacing the current code and therefore only run when required

Should we trap the signal in vash, set an env value and use it with vyos?

If enable is not clear as a name to say that it adds the feature to the class, it is a class decorator, then please suggest a better name.

I will look into the use case and see if I can think of something.

I have implemented a "validator program" which is an entry point which will locate a named python program and run it. It uses the import mechanism of python at startup so the setup time is very high.

I raised this with the team and the idea of auto-detection does not get much support, which is fine, I just wanted to make sure I was doing the right thing. So I will finish this patch which will prevent some failure case and try to make the error message friendlier. Also, can look at where in the chain of change the MTU is performed to see if it can be rolled back.

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

@jjakob it does nothing about the boot case but it would be much easier to add it to that code than what we do ATM.

It seems that github has special rules for the .github file and that no PR can be done for it:
https://github.com/thomas-mangin/vyos-1x/blob/T2436/.github/workflows/pythonapp.yml

I would also suggest doing the same using github actions so that on push to your local repository to get a warning from github.

Why do we need to remove all addresses from the interface when it is disabled?

Can I throw https://github.com/vyos/vyos-1x/blob/current/src/conf_mode/interfaces-tunnel.py#L32 into the mix?

How this can be implemented in practice was tested with https://github.com/thomas-mangin/vyos-extra

• the program can be installed using pip/setuptools and the "vyosextra.main:main" entry point, generating a "vyos" program.
• the "release" program in the root folder generates a self-contained executable (using the builtin python3 zipapp library) which can be place before in the path, taking precedence over the installed version.
• each feature "vyos ssh", "vyos update" is a single program and could be installed independently using other entry points
• dropping a program in the folder automatically registers it to the main "vyos" program, each program has a "def main()" with a docstring used for the "-h"
• the assets in the data folder are converted into python dict and used when the program is a zipapp.

@jjakob I was going to offer to do so this week if people agreed to give me a chance to show good it could be.

Using shell scripts would be a step back. The biggest part of the python script is the parsing of the vyos code. That's why I am suggesting that vyos command should be sent to a python daemon.
We can connect to it using IPC, and this can be done via a small C wrapper (or even directly in the caller's code to not even fork).

vyos@vyos# time bash -c ""

I was also wondering if we should attempt an auto-detection of MTU on boot and save the result? This is why I was asking if this was the right approach.

Not sure if this is the right approach or not. Feedback welcomed.

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

ack - I will change this to make sure it is safe !

Some code should also be added to detect the parent MTU size and make sure a clan MTU is smaller than the parent

The mtu provided are reasonable and should not fail IMHO. I need to understand why Linux does not want to honour it.. hw limitation or other. If it is a limitation then we should detect it and report it to the user

That would only hide the problem. The MTU bug would still be here.

An issue to change the MTU should not fail the whole interface change but just this one but the code does not not allow this easily. I will try to work on this.

The reason seems to be that when the kernel can not change the MTU when writing to the sysfs, it will raise a OSError with the reason why.

I had already reported before my refactor of the code that DHCPv6 does not work.
https://phabricator.vyos.net/T2268

http://man7.org/linux/man-pages/man8/start-stop-daemon.8.html

EXIT STATUS

https://vincent.bernat.ch/en/blog/2017-ipv6-route-lookup-linux

Marek Isalski Today at 6:31 PM

@jjakob sorry for wasting your time here :-( I will try to replicate.

@Merjin is trying this:

sudo sysctl -w net.ipv6.route.max_size=131072

https://serverfault.com/questions/902161/linux-host-randomly-stops-answering-ipv6-neighbor-solicitation-requests
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861115

To explain the permission for the user/group/world are expressed in octal (3 bits) so 755 is binary for 111 101 101

@jjakob can we close this task ?

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

Should a iproute.py wrapper be considered to prevent having calls to "ip" everywhere in the code?
Therefore if at a later date a better solution comes along the calls to binary would not be everywhere in the code ?

Fair enough. I have gone thought the bug tracker of pyroute2 and indeed it does not inspire confidence!

any L2/L3 issue affecting TCP between the BGP speaker will cause this message. Looking forward to a TCP dump of the traffic when it occurs.

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

I agree but it will be quite some work ... I would happy to work on this as it would remove my of my issues with calling "cmd()" for network interface setting.

@jjakob if you enable debugging and record what is happening to the interface when it drops would be useful.

For clarity, I do not believe the rewrite in the parent task is the root of the issue, as the behaviour on configuration was not changed. The code was restructured but the action logic remained the same. The same commands/actions will be run now as were run before the patchset. If something changed it will be in the conf mode interface code and not ifconfig AFAICS

Yes the code always does down / up. It is something @cpo and I discussed and it was deemed safer when performing changes. There could be a way to indicate that a change occur which should cause a trigger in another section. Something all sections should run on every change. This would be a major design change as we would not anymore apply everything, would need to decide what part of the change trigger this update process and implement a new section and make sure it is run !

@jjakob this is the wrong phabricator entry to discuss it but I got your point ;-)

This is correct.

@jjakob https://github.com/vyos/vyos-1x/pull/376

The file should have been 660 and it should have worked .. I will check

Yes, I also have a patch ... somewhere .. which prevent to change any of the /config files on the system (so that a user can not make damage to the system).
I also need to add a check to only use the file if the user and permission are what is expected. I will do it :-)
The file should be created as group vyattacfg tho with rights allowing both the user and root to write to it.

@jjakob There is no need to check if an interface exists before creation, the code has always tried to find the interface and use it if there, otherwise it will create it.

@jjakob yes, what you propose to check if an interface exists is good. If you know the type (as defined in the class which as the same name as the "set interface" section such as ethernet) you can use Section.interfaces('ethernet') to only get what you want.

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

First, I thought you had merged the patch, as you did not, there is no duplication ATM.

This may possibly be the cause of some bugs?

If the interface exists, it is perfectly harmless: it was the previous behaviour. The example where it can cause issue when a interface name is used and does not exists as it will create it. So really op_mode commands.

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

https://github.com/vyos/vyos-1x/pull/372 will now not display tunnel (but gre-bridge) as options for bridge. Still not preventing them to be used.

works if run as root (or sudo) but not as it.

/sys/class/ieee80211 does not exist on VirtualBox perhaps the interface configuration should fail it is missing ?

So the commands were not on crux under the tunnel section and trying to use either ip link or brctl is failing:

For all the bridge issues, I wanted to see what was happening on crux, taking T2356 as reference:

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

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

Works for me ..

[ interfaces tunnel tun0 ]
DEBUG/IFCONFIG cmd 'ip tunnel add tun0 mode gre local 127.0.0.1 remote 1.1.1.1 dev eth0 ttl 255 tos inherit'

The code has the concept of options which can be infered from the default dict and thefore should probably be removed for simplication.

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

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

could you please try this patch. if it still fails, can you remove the 'mtu' from the 'options' line and try again ?

diff --git a/python/vyos/ifconfig/tunnel.py b/python/vyos/ifconfig/tunnel.py
index 0506066..46900ce 100644
--- a/python/vyos/ifconfig/tunnel.py
+++ b/python/vyos/ifconfig/tunnel.py
@@ -141,8 +141,8 @@ class GREIf(_Tunnel):
     default = {'type': 'gre'}
     required = ['local', ]  # mGRE is a GRE without remote endpoint