Age | Commit message (Collapse) | Author |
|
As PPP can be used to establish a connection on-demand it manages the Kernel
default route. This can not be used when using VRFs which are managed by
the ip-up.d and ip-down.d scripts - thus those options are now mutially
exclusive.
The best fix would be adding support for VRFs into PPP.
|
|
Commit ef27cef0 mistakenly removed client-config-dir from the
server template.
|
|
|
|
- rearranged options to put them in logical groups separated by blank
lines
- removed unnecessary blank lines (whitespace)
- fixed encryption if-else comparison logic that caused 3des to be
ignored
- set tls if tls-version-min is set
|
|
|
|
|
|
wireless: T2233: bugfix: Typos in Jinja2 syntax
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
VHT flags deal with many variables which depend on antenna count and
supported features. BF-ANTENNA-(2|3|4) and SOUNDING-DIMENSION-(2|3|4)
were not dealt with correctly.
IEEE 802.11ac (VHT) supports at least 1 antenna and up to 8 antennas
at most. The hsotapd VHT flags may support as many but most do not.
Therefore, we need to be picky here...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The old implementation actually did not work as the Quotes "" around the
"vrf foo" statement got actually lost in translation.
|