| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Allow syslog messages to be sent through a VRF (e.g. management).
|
|
|
|
Debian's `debian/2%2.10-12` update of the hostap packaging added a
ConditionFileNotEmpty directive for `/etc/hostapd/<...>` paths, which
doesn't match the `/run/hostapd/<...>` paths that VyOS uses. This commit
updates the override file to use the proper VyOS paths.
https://salsa.debian.org/debian/wpa/-/commit/d204ceb5a2dc33db888eb55b5fee542a1005e69c
Signed-off-by: Andrew Gunnerson <accounts+github@chiller3.com>
|
|
Rewritten opennhrp script using vyos.ipsec library
|
|
Add numbers for all dhclient-exit-hooks.d to enforce script order execution
Also, move '99-run-user-hooks' to '98-run-user-hooks' due to
vyatta-dhclient-hook bug and exit with 'exit 1' it is
described in the https://vyos.dev/T4856, so we should move this hook
to the end. Rename 'vyatta-dhclient-hook' to '99-vyatta-dhclient-hook'
|
|
Commit cb872efb ("frr: T5045: lift LimitNOFILE 1024 -> 4096") added both
LimitNOFILE and LimitNOFILESoft parameters for FRR, as "systemctl cat frr.service"
showed both versions.
During daemon startup systemd complains:
Unknown key name 'LimitNOFILESoft' in section 'Service', ignoring.
So the key got removed again.
|
|
Also ExecReload is a duplicate of the base service file
|
|
|
|
Lift the amount of allowed open file descriptors for the FRR process tree.
Required if there are hundreds to thousands interfaces on a system.
|
|
This commit adds a script to run user-defined hook scripts upon renewing
a DHCP lease. This can be used to, for example, dynamically define a
firewall address-group based on the dynamic IP address of an interface.
For an example of its use (as well as the use case I had in mind while
coding this), see https://vyos.dev/T2196#142394
Co-authored-by: br <git@ibeep.com>
|
|
|
|
Replace links to the phabricator site from https://phabricator.vyos.net to
https://vyos.dev
|
|
|
|
This sysctl has been removed from kernel 6.0.X onwards but its removal was skipped when upgrading the kernel.
See: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/net/netfilter?id=b118509076b39cc5e616c0680312b5caaca535fe
|
|
|
|
Our python scripts use the shebang logic to set an intepreter - we should
rely on this and not use an external interpreter in front of the helper.
|
|
vyos@vyos# show interfaces sstpc
sstpc sstpc10 {
authentication {
password vyos
user vyos
}
server sstp.vyos.net
ssl {
ca-certificate VyOS-CA
}
}
|
|
ip-up/down scripts added in https://github.com/vyos/vyos-1x/pull/1656
need the executable bit.
|
|
1. When a PPPoE session is connected, `pppd` will update
`/etc/resolv.conf` regardless of `system name-server` option unless `no-peer-dns` is set.
This is because `pppd` vendors scripts `/etc/ppp/ip-up.d/0000usepeerdns` and `/etc/ppp/ip-down.d/0000usepeerdns`,
which updates `/etc/resolv.conf` on PPPoE connection and reverts the change on disconnection.
This PR removes those scripts and adds custom scripts to update name server entries through `vyos-hostsd` instead.
2. There is a typo in `/etc/dhcp/dhclient-enter-hooks.d/04-vyos-resolvconf, which misspells variable name `new_dhcp6_name_servers` as `new_dhcpv6_name_servers`.
This causes IPv6 name server entries in `vyos-hostsd` not updated
when dhclient receives nameservers from DHCPv6.
3. Regular expressions in scripts under `/etc/dhcp/dhclient-enter-hooks.d` and
`/etc/dhcp/dhclient-exit-hooks.d/` are not enclosed in `^$`, so those
IPv4 related branches (like `BOUND`) could be mistakenly executed when an IPv6
reason (like `BOUND6`) is given.
|
|
Unprivileged RADIUS users cannot do simple diagnostics like ping
or traceroute. Allow them such tools.
Ability to execute op-mode commands for them.
It is not new 'operator mode' feature but it allows RADIUS users
execute op-mode commands
|
|
Telegraf checks the firewall table 'vyos_filter' but it we don't
have any firewall in the system we don't have this table by default
It cause commit error for "service monitoring"
Add exception if the table "vyos_filter" is not found
|
|
The initial implementation from commit ac4e07f9 ("rfs: T4689: Support RFS
(Receive Flow Steering)") always adjusted the global rps_sock_flow_entries
configuration. So if RFS was enabled for one NIC but not the other - it did not
work.
According to the documentation:
RFS is only available if the kconfig symbol CONFIG_RPS is enabled (on by
default for SMP). The functionality remains disabled until explicitly
configured. The number of entries in the global flow table is set through:
/proc/sys/net/core/rps_sock_flow_entries
The number of entries in the per-queue flow table are set through:
/sys/class/net/<dev>/queues/rx-<n>/rps_flow_cnt
Both of these need to be set before RFS is enabled for a receive queue. Values
for both are rounded up to the nearest power of two. The suggested flow count
depends on the expected number of active connections at any given time, which
may be significantly less than the number of open connections. We have found
that a value of 32768 for rps_sock_flow_entries works fairly well on a
moderately loaded server.
This commit sets rps_sock_flow_entries via sysctl on bootup leafing the RFS
configuration to the interface level.
|
|
|
|
opennhrp: T1070: Fixed creating IPSEC tunnel to Hub
|
|
Section.interface()
Commit cfde4b49 ("ifconfig: T2223: add vlan switch for Section.interfaces()")
added the functionality of the local get_interfaces() function to the base
class so all other parts in the system can query for interface names of a given
type including or excluding their vlan sub-interfaces.
|
|
Fixed creating IPSEC tunnel to Hub. Added continues of execution
generator functions.
|
|
Fixed removal all dmvpn SAs. Changed vici terminate by child-sa
name on terminate by ike-id
|
|
When MACsec was bound to an ethernet interface and the underlaying
source-interface got changed (even description only) this terminated the
MACsec session running on top of it.
The root cause is when EAPoL was implemented in commit d59354e52a8a7f we
re-used the same systemd unit which is responsible for MACsec. That indeed lead
to the fact that wpa_supplicant was always stopped when anything happened on
the underlaying source-interface that was not related to EAPoL.
|
|
|
|
Fixed incorrect key to get gateway for route add command
|
|
|
|
nhrp: T4546: Fixed route add command if MTU presented
|
|
|
|
In case if `NHRP_DESTMTU` environment variable is presented, the
script uses an intermediate command to get the current route
before adding a new one. Then received data is used in the
`route add` command generation. This commit fixes this process,
so setting MTU becomes possible.
|
|
|
|
Directed broadcast is described in rfc1812#section-5.3.5.2 and rfc2644.
By default Linux kernel doesn't forward directed broadcast
packets unless both of `/proc/sys/net/ipv4/conf/all/bc_forwarding`
and `/proc/sys/net/ipv4/conf/$iface/bc_forwarding` are set to 1.
|
|
After discussion with @zsdc this was decided the better long term fix
* Removes hourly logrotate cron in favour of systemd timer override
|
|
|
|
|
|
- Default dhclient script only uses value of `$IF_MERIC` envvar for default route recived via `router` option.
- This variable has no effect on rotes received via `rfc3442-classless-static-routes` option
- Considering that Vyos overrrides `ip` command originating from `dhclient` this can be easily fixed in `iptovtysh()` function by using the `$IF_METRIC` envvar directly in the dhclient hook.
(cherry picked from commit 0c00e7bf8b6e68814607fde4ff0cd70ce9f4b486)
|
|
When VyOS is booting and an interface is brought up (PPPoE) which requires a
user callback script that is executed asynchronously when the interface is up
we can not use Config(). The problem is, Config() is not available when
the system starts and the initial commit is still processed.
We need to move to ConfigTreeQuery() which was build for this exact same
purpose.
|
|
present for DHCP
VyOS 1.4 still leverages PPPd internals on the CLI.
pppd supports three options for a default route, none, auto, force.
* none: No default route is installed on interface up
* auto: Default route is only installed if there is yet no default route
* force: overwrite any default route
There are several drawbacks in this design for VyOS and the users. If auto is
specified, this only counted for static default routes - but what about dynamic
ones? Same for force, only a static default route got replaced but dynamic ones
did not got taken into account.
The CLI is changed and we now re-use already existing nodes from the DHCP
interface configuration:
* no-default-route:
On link up no default route is installed, same as the previous
default-route none
* default-route-distance:
We can now specify the distance of this route for the routing table on the
system. This defaults to 210 as we have for DHCP interfaces. All this will be
migrated using a CLI migration script.
|
|
does not terminate"
This reverts commit dda1b02932a5108ef257f59323dcfcf82582b805.
|
|
not terminate
|
|
|
|
This reverts commit 1cbcbf40b7721849f9696c05fac65db010a66b7c.
|
|
* Removed `/var/log/auth.log` and `/var/log/messages` from
`/etc/logrotate.d/rsyslog`, because they conflict with VyOS-controlled
items what leads to service error.
* Removed generation config file for `/var/log/messages` from
`system-syslog.py` - this should be done from `syslom logs` now.
* Generate each logfile from `system syslog file` to a dedicated
logrotate config file.
* Fixed logrotate config file names in
`/etc/rsyslog.d/vyos-rsyslog.conf`.
* Added default logrotate settins for `/var/log/messages`
|
|
|
|
It should be possible to send the gathered data via a VRF bound interface to
the collector. This is somehow related to T3981 but it's the opposite side of
the netflow process.
set system flow-accounting vrf <name>
|
