@thomas-mangin the sessions are still stable, for 7 days now. The only thing changed was that max_size limit. Also no packetloss on the IPv6 connections has been observed during this time.

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

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

Nice catch - I was not aware of that show command.

The issue has been solved by the above merge.

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

@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

How I reproduce it.

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

Successfully tested on 1.3-rolling-202004270117

PR https://github.com/vyos/vyos-1x/pull/382

@jjakob can we close this task ?

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.

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!

@c-po errors in latest rolling VyOS 1.3-rolling-202004270117

$ show poweroff
Traceback (most recent call last):
  File "/usr/libexec/vyos/op_mode/powerctrl.py", line 193, in <module>
    main()
  File "/usr/libexec/vyos/op_mode/powerctrl.py", line 188, in main
    check_shutdown()
  File "/usr/libexec/vyos/op_mode/powerctrl.py", line 74, in check_shutdown
    dt = datetime.strptime(output['DATETIME'], '%Y-%m-%d %H:%M:%S')
TypeError: 'NoneType' object is not subscriptable

Nope. Before I‘ve invented vyos.ifconfig it was actually based on pyroute2. The problem with pyroute2 was that it lacked required functionality for VyOS which let me to developing our own lib.

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.

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)

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.

@elbandi how should this approach fix the error on image upgrade?

PR https://github.com/vyos/vyos-1x/pull/378

Just call the multiple options other name (like 'option'), and admin can modify they config if they want. no need a IM migrate script.
And leave the openvpn-option for raw option, if someone want to make a magic things in openvpn.
(like, in dhcp server, static mapping has option tagnode for "Host-specific settings" and static-mapping-parameters for raw hacking :)

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.

@elbandi sure that I used as workaround.

sould rewrite to multioption:

• rename hash_type -> hash
• rename mine_interval -> interval