GitLab

Turns out we were not using the broadcom recommended way for setting
up macvlan interface, that support is added now.

Test:
- No regression in any deployment
- Test script that was failing since crash was observed now passes.
- Couple of more config scenarios in which kernel crashed also stand
  resolved now.

Support for 8021ad interface with name ethx.y.z is restricted
to broadcom platform having vlanconf for now. This resolves the
regression on ex400 when both switch and device section are present
and device section is used only to configure mac address on the
pre-existing interface on the switch.

Test:
- 8021ad interface with name ethx.y.z is supported on panther.
- regression tests for all deployments on panther pass.
- ssh and ping to ex400 is possible.
- wan interface on ex400 can get the IP address from upstream
  dhcp server.

Descriptions and cause
----------------------
During the implementation of the provider bridge deployment scenario,
it came to light that netifd has an inherent restriction that the 8021ad
vlan cannot be setup using the linux naming convention, that is, ethx.y.z

This restriction stems from the initial implementation:
https://git.openwrt.org/?p=project/netifd.git;a=commit;h=59217785704fca27d2c7a19e279d27c384a452cd

I can understand that this restriction was introduced becuase netifd has
ways on internally generating vlans in case the corresponding device section is
not mentioned. So, if ethx.y is the ifname in the interface section and the
corresponding device section with name ethx.y does not exist, it would
create ethx.y. What is worth noting here is that at this junture, since the
device section is not even consulted, netifd has no way of knowing the type
of this vlan interface, hence, it assumes it to 8021q and sets up the vlans accordingly.

If this same naming convention is used, then if ethx.y.z is ifname in interface section
then ethx.y is created first and then ethx.y.z on top of ethx.y, however, since netifd
does not consult the device section, it creates both vlans as 8021q.

Solution
--------
if device section for a vlan interface mentioned as ifname in interface
section is present, then create vlan using the parameters mentioned
in the corresponding device section. This should not break the traditional
openwrt behaviour as well and hence, in my opinion is a more suited
candidate to resolve bug #3270.

This new section allows us to assign mac specific key/vid settings to a
station.
Signed-off-by: John Crispin <john@phrozen.org>
(cherry picked from commit a56b457656218e5b6142b6238286ea54801ac4b2)

This new section allows us to create apvlan settings for hostapd.
Signed-off-by: John Crispin <john@phrozen.org>
(cherry picked from commit 4ce33cee34e413f69082a80a833f3ed1baf8a761)

Read dscp2pbit mapping from the uci and pass to vlanconf script
so that the same can be configured on a broadcom device.

- Add support to pass ingress_qos_map to vlanconf script.

It allows setting mappings for instance this way:
"""
config device
  option name 'vlan41'
  option type '8021q'
  option vid '41'
  option ifname 'eth1'
  list   ingress_qos_mapping '1:2'
  list   ingress_qos_mapping '2:5'
  list   egress_qos_mapping '0:3'
"""
Signed-off-by: Pau Espin Pedrol <pespin.shar@gmail.com>
Tested-by: Pedro <pedrowrt@cas.cat>

Option to support vlan translation added to network uci file and
hence netifd updated. In case its a broadcom chip, that is, if
vlanconf is detected, then use this option to configure vlan
translation.

Test via autotest and also manually (to verify the p-bit is not
overwritten). Rest of the scenarios work as expected wih the
existing conf so no regression

Fix cb leak in case invalid type is specified in system_if_clear_entries
Detected by Coverity in CID1431183
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>

Fixes CID 1220430, 1432226, 1432807 and 1433508
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>

-xfrm interfaces were deleted before
-use standard parameters for xfrm interface created
Signed-off-by: André Valentin <avalentin@marcant.net>

Reported by Coverity in CID 1445749
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>

No need to check if dev is NULL as device is always set when
system_neigh is called

Fixes issue reported by Coverity in CID 1445818
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>

This adds support for xfrm interfaces. These interfaces can be used since
linux 4.19 for IPsec traffic, like VTI interface.
XFRM interfaces are less complicated compared to VTI because they need no IP
tunnel endpoints.

Since commit 5cf79759 (iprule: rework
interface based rules to handle dynamic interfaces) the rule
comparison is broken and doesn't correctly recognize matching rules.
This in turn break the reloading as adding the "new" rule fails
because it already exists and it then delete the "old" rule.

The comparison is broken because it now include fields that are not
defining the rule itself, as well as some pointer to malloced strings.
To fix this we move back the offending fields in the iprule struct
before the 'flags' field and match the malloced strings separately.
Signed-off-by: Alban Bedel <albeu@free.fr>
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>

In case of tunnel over PPP(such as gretap over l2tp): tunnel interface
use PPP's peer address as remote address, netifd script will call
proto_add_host_dependency function, then netifd will search which device
can reach to the remote address. Before the patch, netifd don't consider
the PPP interface can reach to the remote address, so netifd will select
default route to remote address, it will lead to remote address unreachable.

Based on a patch by xiaofan <xfan1024@live.com>
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>

blobmsg_check_attr() takes as second argument a bool; fix it where needed
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>

Failing to set the IPv6 mtu is only a real issue if the mtu to be set is
smaller than the current mtu as in that case it would break IPv6 path mtu;
adapt the logic to generate the warning accordingly
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>

Add missing space to change from:

netifd: Failed to set IPv6 mtu to 1500on interface 'wg0'

to:

netifd: Failed to set IPv6 mtu to 1500 on interface 'wg0'
Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>

Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>

The neighbor or neighbor6 network section makes neighbours
configurable via UCI or proto shell handlers. It allows to
install neighbor proxy entries or static neighbor entries

The neighbor or neighbor6 section has the following types:
	interface : declares the logical OpenWrt interface
	ipaddr : the ip address of the neighbor
	mac : the mac address of the neighbor
	proxy : specifies whether the neighbor ia a proxy
		entry (can be 1 or 0)
	router : specifies whether the neighbor is a router
		 (can be 1 or 0)
Signed-off-by: Alexander Meuris <meurisalexander@gmail.com>
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>

commit a97297d8 ("interface: set interface in TEARDOWN state when checking link state")
broke the if-down hotplug event handling, as the iface->state is now IFS_TEARDOWN when
calling the mark_interface_down() function from the IFPEV_DOWN event.

Fixes: a97297d8 ("interface: set interface in TEARDOWN state when checking link state")
Signed-off-by: Martin Schiller <ms@dev.tdt.de>

In case PROTO_CMD_SETUP cannot be handled due to an invalid state; return
-1 so the calling functions are aware the PROTO_CMD_SETUP has failed.
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>

When launching PROTO_CMD_TEARDOWN in interface_check_state() the interface
was set in IFS_DOWN state. In case an interface is now brought into IFS_SETUP
state in __interface_set_up() it will launch PROTO_CMD_SETUP trying to
bring the proto shell handler in S_SETUP state which will fail as the proto
shell handler is still in the S_TEARDOWN state.

Fix this by setting the interface in IFS_TEARDOWN state when the PROTO_CMD_TEARDOWN
event is launched which will prevent the interface being brought into IFS_SETUP state
as long as it's not in the IFS_DOWN state.
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>

This simple patch adds 802.11ad to hwmode list so that netifd-wireless.sh does not otherwise overwrite it with the default hwmode=g
Signed-off-by: Robert Marko <robimarko@gmail.com>

This patch will add support for using GCMP as cipher suite.
This is not a strong cipher but is only one supported by
wil6210 driver in order to have encrypted traffic.
Signed-off-by: Robert Marko <robimarko@gmail.com>