Is this normal?
vyos@rt-home# set interfaces ethernet eth4 vif 20 [edit] vyos@rt-home# commit [ interfaces ethernet eth4 ] DEBUG/ifconfig cmd '/sbin/ethtool -K eth4 gro off' DEBUG/ifconfig cmd '/sbin/ethtool -K eth4 gso off' DEBUG/ifconfig cmd '/sbin/ethtool -K eth4 sg off' DEBUG/ifconfig cmd '/sbin/ethtool -K eth4 tso off' DEBUG/ifconfig cmd '/sbin/ethtool -K eth4 ufo off' DEBUG/ifconfig returned: Cannot change udp-fragmentation-offload
Please find below, with some comments redacted.
I can't reproduce it with the code in the rolling image that will be available by tomorrow.
Re-assigning to @Dmitry after checking with him as he's more experienced here.
Where do I get the local address from? Can you share your complete config? Maybe we need source-address or something similar in CLI.
Yes - there are some parts which make use of this bad practice (mostly introduced by me), cleanup required.
There is an issue with storing the state of the interface and then applying it in bulk. For some interface we want to admin it down before performing change and then bringing it back up.
If we store this then only the change and the up command will be applied, this is not going to work.
@cpo should another task be created to make sure we exclude the interfaces themself from source-interface (s) ?
Hello, @adestis!
Support of transition-scripts was added to sync-groups in a rolling version.
PR for this task https://github.com/vyos/vyos-1x/pull/313
thanks to @runborg .. my own initial attempt to syslog failed (facility level ??)
This works
import logging
import logging.handlers
my_logger = logging.getLogger('MyLogger') # logger is singleton
my_logger.setLevel(logging.DEBUG)
handler = logging.handlers.SysLogHandler(address='/dev/log', facility="auth")
my_logger.addHandler(handler)
my_logger.critical('this is critical')from shlex import quote
def systemd(self, level, message):
msg = quote(message)
run(f'echo {msg} | systemd-cat -p {self.level}')Personally I'd use systemd-journald which I think provides the same logging facilities as rsyslog used to, but vyos still runs both. IMO the logging section is a mess and would need a complete rewrite to journal.
# sudo lsof | grep dev-log I am officially daft .. I thought it was not running !
@dmbaturin I was aked on slack to report the information via syslog. However the syslog server is not listening on on UDP port 514 on localhost. How would you like to proceed ?
should it be opened (I am not sure where this should be configured) or should the log be written on the drive using the python logging module (as I currently have implemented).
@cpo AFAIU the patches are not right as the code making use of Config() in the verify() section and AFAIU this is against the separation between get_config()
Already possible via Cloud-init. For different environments may be required differently tuned images (data sources, additional tools like guest agents, etc.).
Looks good. I don't have merge access but this definitely is a fix to an oversight in the build.
@chrismarget we autogenerate list of resolved issues for releases
so tasks names should be with more context
Not really, just make sure you include VyOS 1.3 project so we can track what can be backported
you will need to adjust your PR message to include task number T2239
Did I do the wrong thing by tagging this for vyos-build?
vyos@R3# run show version all | match strongswan ii strongswan 5.7.2-1 all IPsec VPN solution metapackage
But in this case, we have an issue with command
vyos@R3# sudo ip link add tun0 type gretap local 0.0.0.0 RTNETLINK answers: File exists
In old scripts, tunnels were created by following commands
ip tunnel add tun0 local 0.0.0.0 mode gre key 1 ttl 255 tos inherit ip link set tun0 multicast on allmulticast on up ip addr add 10.0.0.4/24 broadcast + dev tun0 ip tunnel cha tun0 local 0.0.0.0
@Dmitry @c-po is this an other version of strongswan? or is this the strongswan with dmvpn pathes in from vyos repo?
The main reason for this issue - we can't create properly tunnel
set interfaces tunnel tun0 address 10.0.0.3/24 set interfaces tunnel tun0 encapsulation gre set interfaces tunnel tun0 local-ip 0.0.0.0 set interfaces tunnel tun0 multicast enable set interfaces tunnel tun0 parameters ip key 1
@c-po let me reproduce this locally, I will find an answer.
@Dmitry maybe you have an idea why?
If you comment out this line, arp after reboot doesn't lose.
@dongjunbo Can you send an example?