| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
As PPPoE interfaces should be part of a VRF it is required that the default
can also be set into the specified VRF. The default way of PPP by setting the
"defaultroute" option does not take a VRF into account. In this case PPP
installs a Kernel route forwarding all default traffic over this interface.
This change installs a static route with metric 1 instead into the routing
table via FRR. This is not the same as a Kernel route in terms of metric 1
compared to 0 but it should do the trick.
|
|
|
|
|
|
This makes the actual code which generates the configs much more human
readable.
|
|
This makes the actual code which generates the configs much more human
readable.
|
|
|
|
|
