openwrt / netifd Goto Github PK

[MIRROR] OpenWrt Network interface configuration daemon

Home Page: https://git.openwrt.org/?p=project/netifd.git;

CMake 0.35% C 96.36% Shell 3.29%

netifd's Issues

Custom route fails to work without setting gateway

This is my network config:

config interface 'loopback'
	option device 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fdac:2bfe:d5cf::/48'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'lan1'
	list ports 'lan2'
	list ports 'lan3'
	list ports 'sfp2'

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option ipaddr '10.254.100.1/24'
	option netmask '255.255.255.0'
	option ip6assign '60'
	option dns '10.254.100.1'

config device
	option name 'br-wan'
	option type 'bridge'
	option macaddr 'CE:3B:48:7D:DB:62'
	list ports 'eth1'
	list ports 'wan'

config device
	option name 'eth1'
	option macaddr 'ce:3b:48:7d:db:62'

config device
	option name 'wan'
	option macaddr 'ce:3b:48:7d:db:62'

config interface 'wan'
	option device 'br-wan'
	option start '100'
	option limit '150'
	option leasetime '12h'
	option metric '10'
	option proto 'pppoe'
	option username '<username>'
	option password '<password>'
	option ipv6 '0'

config interface 'wan6'
	option device '@wan'
	option metric '10'
	option reqaddress 'try'
	option reqprefix 'auto'
	option sourcefilter '0'
	option proto 'dhcpv6'

config interface '4G'
	option proto 'qmi'
	option auth 'none'
	option pdptype 'ipv4v6'
	option device '/dev/cdc-wdm0'
	option metric '50'
	option delegate '0'

config interface 'BSNLTrunk'
	option device 'lan4'
	option proto 'dhcp'
	option metric '1000'
	option delegate '0'

config interface 'tailscale'
	option proto 'none'
	option device 'tailscale0'

This is my firewall config:

config defaults
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option synflood_protect '1'

config zone
	option name 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	list network 'lan'

config zone
	option name 'wan'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option masq '1'
	option mtu_fix '1'
	list network 'wan'
	list network 'wan6'
	list network '4G'
	list network 'BSNLTrunk'

config forwarding
	option src 'lan'
	option dest 'wan'
	
config rule
	option name 'Allow-DHCP-Renew'
	option src 'wan'
	option proto 'udp'
	option dest_port '68'
	option target 'ACCEPT'
	option family 'ipv4'

config rule
	option name 'Allow-IGMP'
	option src 'wan'
	option proto 'igmp'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-DHCPv6'
	option src 'wan'
	option proto 'udp'
	option dest_port '546'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-MLD'
	option src 'wan'
	option proto 'icmp'
	option src_ip 'fe80::/10'
	list icmp_type '130/0'
	list icmp_type '131/0'
	list icmp_type '132/0'
	list icmp_type '143/0'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Input'
	option src 'wan'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	list icmp_type 'router-solicitation'
	list icmp_type 'neighbour-solicitation'
	list icmp_type 'router-advertisement'
	list icmp_type 'neighbour-advertisement'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Forward'
	option src 'wan'
	option dest '*'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config include 'miniupnpd'
	option type 'script'
	option path '/usr/share/miniupnpd/firewall.include'

config zone
	option name 'tailscale'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	option masq '1'
	list network 'tailscale'

config forwarding
	option src 'tailscale'
	option dest 'lan'

config forwarding
	option src 'tailscale'
	option dest 'wan'

config forwarding
	option src 'lan'
	option dest 'tailscale'

Before I set anything up, I can ping 172.30.249.11 and 172.30.249.33 by using the command ping <ip> -I lan4, what I want to achieve is all packets directed to these IPs (and some other IPs that I will add later) to automatically use lan4 (BSNLTrunk). I can see the following data in the overview page as well:

Protocol: DHCP client
Address: 10.148.113.22/19
Gateway: 10.148.96.1
DNS 1: 172.30.249.11
DNS 2: 172.30.249.33
Expires: 1h 15m 56s
Connected: 0h 14m 4s

Now this is my setup :

I mark the packets from anywhere 0.0.0.0/0 to 172.30.249.0/24 using these nftables rules:

/usr/share/nftables.d/chain-pre/mangle_output/0-pbr.nft :

ip saddr { 0.0.0.0/0 } ip daddr { 172.30.249.0/24 } counter meta mark set 720801 comment "!fw4: 720801"

/usr/share/nftables.d/chain-pre/mangle_prerouting/0-pbr.nft :

iifname "br-lan" ip saddr { 0.0.0.0/0 } ip daddr { 172.30.249.0/24 } counter meta mark set 720801 comment "!fw4: 720801"

I setup rules and routes to use the marked packets using these rules in the /etc/config/network file:

config route
	option table '47167'
	option interface 'BSNLTrunk'
	option target '0.0.0.0/0'

config rule
	option mark '720801'
	option lookup '47167'

Now I should ideally be able to ping 172.30.249.0/24 from anywhere in the network right? But that's not the case the pings seemingly go nowhere and the traceroute (from the router to the range) looks like this:

root@openwrt-box:/usr/share/nftables.d# traceroute 172.30.249.11
traceroute to 172.30.249.11 (172.30.249.11), 30 hops max, 46 byte packets
 1  10.148.113.22 (10.148.113.22)  423.972 ms !H  3118.365 ms !H  3120.005 ms !H

Also I should note that in the overview page the gateway has turned into 0.0.0.0?

Protocol: DHCP client
Address: 10.148.113.22/19
Gateway: 0.0.0.0
DNS 1: 172.30.249.11
DNS 2: 172.30.249.33
Expires: 1h 9m 38s
Connected: 0h 20m 22s

Now I should add that I use the same method to PBR using other interfaces (My 4G interface, some wireguard interfaces) and they all work perfectly fine except this one interface. Also when I add the gateway '10.148.96.1' to this route:

config route
	option table '47167'
	option interface 'BSNLTrunk'
	option target '0.0.0.0/0'
	option gateway '10.148.96.1'

It works as expected again (setting the interface BSNLTrunk to a different routing table also works), but I don't want to use the gateway as it's not reliable and prone to change in my case, I want to use the interface directly. I have tried everything I could think of but I can't seem to get it to work. A user on the forum told me it might be a bug so thought I'd post it here.

netifd: IP loss on interface after issuing "/etc/init.d/network restart"

Details

AP with OpenWRT 23.05.02
netifd version 2024-01-04-c18cc79d-1

Configure AP:

Create interface wan (type bridge, DHCP)
Configure SSIDs to use wan network (no encryption, default settings)
Connect clients and launch iperf tests.

When traffic is being generated, disable the AP radios and restart network:

uci set wireless.radio0.disabled=1
uci set wireless.radio1.disabled=1
uci commit wireless 
/etc/init.d/network restart

Sometimes (it doesn't happen always), the interface wan (device br-wan) loss it's IP, and sometimes interface lan (device br-lan) disappears totally.

The following logs are being showed when this happens:

Feb  5 11:44:38 OpenWRT netifd: Network device 'wlan1' link is down
Feb  5 12:44:38 OpenWRT kernel: [ 4416.306722] br-wan: port 2(wlan1) entered disabled state
Feb  5 11:44:41 OpenWRT netifd: wan (8461): udhcpc: broadcasting renew
Feb  5 12:44:41 OpenWRT kernel: [ 4419.307703] br-wan: port 2(wlan1) entered disabled state
Feb  5 12:44:41 OpenWRT kernel: [ 4419.308207] device wlan1 left promiscuous mode
Feb  5 12:44:41 OpenWRT kernel: [ 4419.312205] br-wan: port 2(wlan1) entered disabled state
Feb  5 11:44:42 OpenWRT wpa_supplicant[2191]: Set new config for phy phy1
Feb  5 11:44:42 OpenWRT netifd: Wireless device 'radio0' is now down
Feb  5 11:44:42 OpenWRT netifd: Wireless device 'radio1' is now down
Feb  5 11:44:44 OpenWRT netifd: wan (8461): udhcpc: broadcasting renew
Feb  5 11:44:47 OpenWRT netifd: wan (8461): udhcpc: broadcasting renew
Feb  5 11:44:50 OpenWRT netifd: wan (8461): udhcpc: lease lost, entering init state
Feb  5 11:44:50 OpenWRT netifd: Interface 'wan' has lost the connection
Feb  5 12:44:50 OpenWRT dnsmasq[1]: no servers found in /tmp/resolv.conf.d/resolv.conf.auto, will retry

I checked that reverting c18cc79 commit solves the issue.

Note: the problem doesn't happen if you replace /etc/init.d/network restart with any of this:

/etc/init.d/network reload
ubus call network restart
wifi

netifd does not support mcast_rate

For Freifunk Berlin we have the following wireless config:

# Wifi Config is derived from wireless profile: 'freifunk_default'

# Radio: 11a_standard
config wifi-device 'radio0'
        option type 'mac80211'
        option band '5g'
        option path '1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0+1'
        option htmode 'HE20'
        option channel '36'
        option country 'DE'
        option legacy_rates '0'


config wifi-iface 'radio0_if0'
        option device 'radio0'
        option network 'dhcp'
        option ifname 'wlan5-ff'
        option mode 'ap'
        option encryption 'none'
        option ssid 'berlin.freifunk.net'
        option isolate '1'

config wifi-iface 'radio0_if1'
        option device 'radio0'
        option network 'dhcp'
        option ifname 'wlan5-ffowe'
        option mode 'ap'
        option encryption 'owe'
        option ssid 'berlin.freifunk.net Encrypted'
        option ieee80211w '1'
        option isolate '1'

config wifi-iface 'radio0_if2'
        option device 'radio0'
        option ifname 'wlan5-mesh'
        option mode 'mesh'
        option mesh_id 'Mesh-Freifunk-Berlin'
        option mesh_fwding '0'
        option mcast_rate '12000'
        option network 'mesh_5g'



# Radio: 11g_standard
config wifi-device 'radio1'
        option type 'mac80211'
        option band '2g'
        option path '1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0'
        option htmode 'HE20'
        option channel '13'
        option country 'DE'
        option legacy_rates '0'


config wifi-iface 'radio1_if0'
        option device 'radio1'
        option network 'dhcp'
        option ifname 'wlan2-ff'
        option mode 'ap'
        option encryption 'none'
        option ssid 'berlin.freifunk.net'
        option isolate '1'

config wifi-iface 'radio1_if1'
        option device 'radio1'
        option network 'dhcp'
        option ifname 'wlan2-ffowe'
        option mode 'ap'
        option encryption 'owe'
        option ssid 'berlin.freifunk.net Encrypted'
        option ieee80211w '1'
        option isolate '1'

config wifi-iface 'radio1_if2'
        option device 'radio1'
        option ifname 'wlan2-mesh'
        option mode 'mesh'
        option mesh_id 'Mesh-Freifunk-Berlin'
        option mesh_fwding '0'
        option mcast_rate '12000'
        option network 'mesh_2g'

Netifd does not bring up the mesh devices with this configuration and states that it could not find a parameter mcast_rate:

Tue Aug 15 16:42:52 2023 daemon.notice netifd: radio1 (1819): Could not find the parameter mcast-rate.
Tue Aug 15 16:42:52 2023 daemon.notice netifd: radio1 (1819): Possible mesh parameters are:
Tue Aug 15 16:42:52 2023 daemon.notice netifd: radio1 (1819):  - mesh_retry_timeout
Tue Aug 15 16:42:52 2023 daemon.notice netifd: radio1 (1819):  - mesh_confirm_timeout
Tue Aug 15 16:42:52 2023 daemon.notice netifd: radio1 (1819):  - mesh_holding_timeout
Tue Aug 15 16:42:52 2023 daemon.notice netifd: radio1 (1819):  - mesh_max_peer_links
Tue Aug 15 16:42:52 2023 daemon.notice netifd: radio1 (1819):  - mesh_max_retries
Tue Aug 15 16:42:52 2023 daemon.notice netifd: radio1 (1819):  - mesh_ttl
Tue Aug 15 16:42:52 2023 daemon.notice netifd: radio1 (1819):  - mesh_element_ttl
Tue Aug 15 16:42:52 2023 daemon.notice netifd: radio1 (1819):  - mesh_auto_open_plinks
Tue Aug 15 16:42:52 2023 daemon.notice netifd: radio1 (1819):  - mesh_hwmp_max_preq_retries
Tue Aug 15 16:42:52 2023 daemon.notice netifd: radio1 (1819):  - mesh_path_refresh_time
Tue Aug 15 16:42:52 2023 daemon.notice netifd: radio1 (1819):  - mesh_min_discovery_timeout
Tue Aug 15 16:42:52 2023 daemon.notice netifd: radio1 (1819):  - mesh_hwmp_active_path_timeout
Tue Aug 15 16:42:52 2023 daemon.notice netifd: radio1 (1819):  - mesh_hwmp_preq_min_interval
Tue Aug 15 16:42:52 2023 daemon.notice netifd: radio1 (1819):  - mesh_hwmp_net_diameter_traversal_time
Tue Aug 15 16:42:52 2023 daemon.notice netifd: radio1 (1819):  - mesh_hwmp_rootmode
Tue Aug 15 16:42:52 2023 daemon.notice netifd: radio1 (1819):  - mesh_hwmp_rann_interval
Tue Aug 15 16:42:52 2023 daemon.notice netifd: radio1 (1819):  - mesh_gate_announcements
Tue Aug 15 16:42:52 2023 daemon.notice netifd: radio1 (1819):  - mesh_fwding
Tue Aug 15 16:42:52 2023 daemon.notice netifd: radio1 (1819):  - mesh_sync_offset_max_neighor
Tue Aug 15 16:42:52 2023 daemon.notice netifd: radio1 (1819):  - mesh_rssi_threshold
Tue Aug 15 16:42:52 2023 daemon.notice netifd: radio1 (1819):  - mesh_hwmp_active_path_to_root_timeout
Tue Aug 15 16:42:52 2023 daemon.notice netifd: radio1 (1819):  - mesh_hwmp_root_interval
Tue Aug 15 16:42:52 2023 daemon.notice netifd: radio1 (1819):  - mesh_hwmp_confirmation_interval
Tue Aug 15 16:42:52 2023 daemon.notice netifd: radio1 (1819):  - mesh_power_mode
Tue Aug 15 16:42:52 2023 daemon.notice netifd: radio1 (1819):  - mesh_awake_window
Tue Aug 15 16:42:52 2023 daemon.notice netifd: radio1 (1819):  - mesh_plink_timeout
Tue Aug 15 16:42:52 2023 daemon.notice netifd: radio1 (1819):  - mesh_connected_to_gate
Tue Aug 15 16:42:52 2023 daemon.notice netifd: radio1 (1819):  - mesh_nolearn
Tue Aug 15 16:42:52 2023 daemon.notice netifd: radio1 (1819):  - mesh_connected_to_as

Is this parameter deprecated or it this a bug?

netifd dont include dynamic vlans from hostapd

i have the problem, that the luci wireless page dont show any stations connected to dynamic vlans on wpa2 enterprise or wpa2 personal ppsk. i traced it back to the luci code getting a empty vlan list and therefore dont even look at the vlans. the empty vlan list i traced back again first to ubus, which showed empty vlan list (ubus -v call network.wireless status), and this back to netifd, which dont consider the dynamicaly created vlans from hostapd and therefore the ubus vlan list is empty and therefore luci dont check for any stations on dynamic vlan networks.

here is the output of ubus -v call network.wireless status:

	"radio0": {
		"up": true,
		"pending": false,
		"autostart": true,
		"disabled": false,
		"retry_setup_failed": false,
		"config": {
			"path": "platform/soc/a000000.wifi",
			"channel": "1",
			"band": "2g",
			"htmode": "HT20",
			"cell_density": 0,
			"country": "DE"
		},
		"interfaces": [
			{
				"section": "wifinet3",
				"ifname": "phy0-ap0",
				"config": {
					"mode": "ap",
					"ssid": "HSZ",
					"encryption": "wpa2+ccmp",
					"auth_server": [
						"127.0.0.1"
					],
					"auth_secret": "testing123",
					"dynamic_vlan": 1,
					"auth_port": 1812,
					"vlan_file": "/etc/config/phy0-ap1.hostapd.vlan",
					"vlan_bridge": "br-vlan",
					"eap_reauth_period": 0,
					"mode": "ap",
					"network": [
						"lan"
					]
				},
				"vlans": [
					
				],
				"stations": [
					
				]
			},
			{
				"section": "wifinet4",
				"ifname": "phy0-ap1",
				"config": {
					"mode": "ap",
					"ssid": "HSZLegacy",
					"encryption": "psk2+ccmp",
					"key": "blablabla",
					"wpa_psk_file": "/etc/config/wpa_psk_file",
					"vlan_bridge": "br-vlan",
					"vlan_file": "/etc/config/phy0-ap0.hostapd.vlan",
					"dynamic_vlan": 1,
					"mode": "ap",
					"network": [
						"lan"
					]
				},
				"vlans": [
					
				],
				"stations": [
					
				]
			}
		]
	},
	"radio1": {
		"up": true,
		"pending": false,
		"autostart": true,
		"disabled": false,
		"retry_setup_failed": false,
		"config": {
			"path": "platform/soc/a800000.wifi",
			"channel": "36",
			"band": "5g",
			"htmode": "VHT80",
			"cell_density": 0,
			"country": "DE"
		},
		"interfaces": [
			{
				"section": "default_radio1",
				"ifname": "phy1-ap0",
				"config": {
					"mode": "ap",
					"ssid": "FRITZ!Box 7530 GL",
					"encryption": "psk2",
					"key": "blablabla",
					"ieee80211r": true,
					"ft_over_ds": false,
					"ft_psk_generate_local": true,
					"maclist": [
						"96:46:27:6E:70:1F"
					],
					"network": [
						"unten"
					],
					"mode": "ap"
				},
				"vlans": [
					
				],
				"stations": [
					
				]
			},
			{
				"section": "wifinet2",
				"ifname": "phy1-ap1",
				"config": {
					"mode": "ap",
					"ssid": "HSZ",
					"encryption": "wpa2+ccmp",
					"auth_server": [
						"127.0.0.1"
					],
					"auth_port": 1812,
					"auth_secret": "testing123",
					"dynamic_vlan": 1,
					"vlan_bridge": "br-vlan",
					"vlan_file": "/etc/config/phy1-ap1.hostapd.vlan",
					"eap_reauth_period": 0,
					"mode": "ap",
					"network": [
						"lan"
					]
				},
				"vlans": [
					
				],
				"stations": [
					
				]
			}
		]
	}
}

the output of iwinfo:

phy0-ap0  ESSID: "HSZ"
          Access Point: DC:15:C8:3C:F8:06
          Mode: Master  Channel: 1 (2.412 GHz)  HT Mode: HT20
          Center Channel 1: 1 2: unknown
          Tx-Power: 20 dBm  Link Quality: unknown/70
          Signal: unknown  Noise: -98 dBm
          Bit Rate: unknown
          Encryption: WPA2 802.1X (CCMP)
          Type: nl80211  HW Mode(s): 802.11b/g/n
          Hardware: embedded [Qualcomm Atheros IPQ4019]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy0

phy0-ap0.10 ESSID: unknown
          Access Point: DE:15:C8:3C:F8:06
          Mode: Master (VLAN)  Channel: 1 (2.412 GHz)  HT Mode: HT20
          Center Channel 1: 1 2: unknown
          Tx-Power: 0 dBm  Link Quality: 45/70
          Signal: -65 dBm  Noise: -98 dBm
          Bit Rate: 144.4 MBit/s
          Encryption: unknown
          Type: nl80211  HW Mode(s): 802.11b/g/n
          Hardware: embedded [Qualcomm Atheros IPQ4019]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy0

phy0-ap0.5 ESSID: unknown
          Access Point: DE:15:C8:3C:F8:06
          Mode: Master (VLAN)  Channel: 1 (2.412 GHz)  HT Mode: HT20
          Center Channel 1: 1 2: unknown
          Tx-Power: 0 dBm  Link Quality: unknown/70
          Signal: unknown  Noise: -98 dBm
          Bit Rate: unknown
          Encryption: unknown
          Type: nl80211  HW Mode(s): 802.11b/g/n
          Hardware: embedded [Qualcomm Atheros IPQ4019]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy0

phy0-ap0.69 ESSID: unknown
          Access Point: DE:15:C8:3C:F8:06
          Mode: Master (VLAN)  Channel: 1 (2.412 GHz)  HT Mode: HT20
          Center Channel 1: 1 2: unknown
          Tx-Power: 0 dBm  Link Quality: unknown/70
          Signal: unknown  Noise: -98 dBm
          Bit Rate: unknown
          Encryption: unknown
          Type: nl80211  HW Mode(s): 802.11b/g/n
          Hardware: embedded [Qualcomm Atheros IPQ4019]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy0

phy0-ap0.72 ESSID: unknown
          Access Point: DE:15:C8:3C:F8:06
          Mode: Master (VLAN)  Channel: 1 (2.412 GHz)  HT Mode: HT20
          Center Channel 1: 1 2: unknown
          Tx-Power: 0 dBm  Link Quality: unknown/70
          Signal: unknown  Noise: -98 dBm
          Bit Rate: unknown
          Encryption: unknown
          Type: nl80211  HW Mode(s): 802.11b/g/n
          Hardware: embedded [Qualcomm Atheros IPQ4019]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy0

phy0-ap0.80 ESSID: unknown
          Access Point: DE:15:C8:3C:F8:06
          Mode: Master (VLAN)  Channel: 1 (2.412 GHz)  HT Mode: HT20
          Center Channel 1: 1 2: unknown
          Tx-Power: 0 dBm  Link Quality: unknown/70
          Signal: unknown  Noise: -98 dBm
          Bit Rate: unknown
          Encryption: unknown
          Type: nl80211  HW Mode(s): 802.11b/g/n
          Hardware: embedded [Qualcomm Atheros IPQ4019]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy0

phy0-ap1  ESSID: "HSZLegacy"
          Access Point: DE:15:C8:3C:F8:06
          Mode: Master  Channel: 1 (2.412 GHz)  HT Mode: HT20
          Center Channel 1: 1 2: unknown
          Tx-Power: 20 dBm  Link Quality: unknown/70
          Signal: unknown  Noise: -98 dBm
          Bit Rate: unknown
          Encryption: WPA2 PSK (CCMP)
          Type: nl80211  HW Mode(s): 802.11b/g/n
          Hardware: embedded [Qualcomm Atheros IPQ4019]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy0

phy0-ap1.10 ESSID: unknown
          Access Point: DC:15:C8:3C:F8:06
          Mode: Master (VLAN)  Channel: 1 (2.412 GHz)  HT Mode: HT20
          Center Channel 1: 1 2: unknown
          Tx-Power: 0 dBm  Link Quality: unknown/70
          Signal: unknown  Noise: -98 dBm
          Bit Rate: unknown
          Encryption: unknown
          Type: nl80211  HW Mode(s): 802.11b/g/n
          Hardware: embedded [Qualcomm Atheros IPQ4019]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy0

phy0-ap1.5 ESSID: unknown
          Access Point: DC:15:C8:3C:F8:06
          Mode: Master (VLAN)  Channel: 1 (2.412 GHz)  HT Mode: HT20
          Center Channel 1: 1 2: unknown
          Tx-Power: 0 dBm  Link Quality: unknown/70
          Signal: unknown  Noise: -98 dBm
          Bit Rate: unknown
          Encryption: unknown
          Type: nl80211  HW Mode(s): 802.11b/g/n
          Hardware: embedded [Qualcomm Atheros IPQ4019]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy0

phy0-ap1.69 ESSID: unknown
          Access Point: DC:15:C8:3C:F8:06
          Mode: Master (VLAN)  Channel: 1 (2.412 GHz)  HT Mode: HT20
          Center Channel 1: 1 2: unknown
          Tx-Power: 0 dBm  Link Quality: unknown/70
          Signal: unknown  Noise: -98 dBm
          Bit Rate: unknown
          Encryption: unknown
          Type: nl80211  HW Mode(s): 802.11b/g/n
          Hardware: embedded [Qualcomm Atheros IPQ4019]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy0

phy0-ap1.72 ESSID: unknown
          Access Point: DC:15:C8:3C:F8:06
          Mode: Master (VLAN)  Channel: 1 (2.412 GHz)  HT Mode: HT20
          Center Channel 1: 1 2: unknown
          Tx-Power: 0 dBm  Link Quality: unknown/70
          Signal: unknown  Noise: -98 dBm
          Bit Rate: unknown
          Encryption: unknown
          Type: nl80211  HW Mode(s): 802.11b/g/n
          Hardware: embedded [Qualcomm Atheros IPQ4019]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy0

phy0-ap1.80 ESSID: unknown
          Access Point: DC:15:C8:3C:F8:06
          Mode: Master (VLAN)  Channel: 1 (2.412 GHz)  HT Mode: HT20
          Center Channel 1: 1 2: unknown
          Tx-Power: 0 dBm  Link Quality: unknown/70
          Signal: unknown  Noise: -98 dBm
          Bit Rate: unknown
          Encryption: unknown
          Type: nl80211  HW Mode(s): 802.11b/g/n
          Hardware: embedded [Qualcomm Atheros IPQ4019]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy0

phy1-ap0  ESSID: "FRITZ!Box 7530 GL"
          Access Point: DC:15:C8:3C:F8:07
          Mode: Master  Channel: 36 (5.180 GHz)  HT Mode: VHT80
          Center Channel 1: 42 2: unknown
          Tx-Power: 23 dBm  Link Quality: 10/70
          Signal: -100 dBm  Noise: -110 dBm
          Bit Rate: 237.8 MBit/s
          Encryption: WPA2 PSK (CCMP)
          Type: nl80211  HW Mode(s): 802.11ac/n
          Hardware: embedded [Qualcomm Atheros IPQ4019]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy1

phy1-ap1  ESSID: "HSZ"
          Access Point: DE:15:C8:3C:F8:07
          Mode: Master  Channel: 36 (5.180 GHz)  HT Mode: VHT80
          Center Channel 1: 42 2: unknown
          Tx-Power: 23 dBm  Link Quality: unknown/70
          Signal: unknown  Noise: -110 dBm
          Bit Rate: unknown
          Encryption: WPA2 802.1X (CCMP)
          Type: nl80211  HW Mode(s): 802.11ac/n
          Hardware: embedded [Qualcomm Atheros IPQ4019]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy1

phy1-ap1.10 ESSID: unknown
          Access Point: DE:15:C8:3C:F8:07
          Mode: Master (VLAN)  Channel: 36 (5.180 GHz)  HT Mode: VHT80
          Center Channel 1: 42 2: unknown
          Tx-Power: 0 dBm  Link Quality: unknown/70
          Signal: unknown  Noise: -110 dBm
          Bit Rate: unknown
          Encryption: unknown
          Type: nl80211  HW Mode(s): 802.11ac/n
          Hardware: embedded [Qualcomm Atheros IPQ4019]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy1

phy1-ap1.5 ESSID: unknown
          Access Point: DE:15:C8:3C:F8:07
          Mode: Master (VLAN)  Channel: 36 (5.180 GHz)  HT Mode: VHT80
          Center Channel 1: 42 2: unknown
          Tx-Power: 0 dBm  Link Quality: unknown/70
          Signal: unknown  Noise: -110 dBm
          Bit Rate: unknown
          Encryption: unknown
          Type: nl80211  HW Mode(s): 802.11ac/n
          Hardware: embedded [Qualcomm Atheros IPQ4019]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy1

phy1-ap1.69 ESSID: unknown
          Access Point: DE:15:C8:3C:F8:07
          Mode: Master (VLAN)  Channel: 36 (5.180 GHz)  HT Mode: VHT80
          Center Channel 1: 42 2: unknown
          Tx-Power: 0 dBm  Link Quality: unknown/70
          Signal: unknown  Noise: -110 dBm
          Bit Rate: unknown
          Encryption: unknown
          Type: nl80211  HW Mode(s): 802.11ac/n
          Hardware: embedded [Qualcomm Atheros IPQ4019]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy1

phy1-ap1.72 ESSID: unknown
          Access Point: DE:15:C8:3C:F8:07
          Mode: Master (VLAN)  Channel: 36 (5.180 GHz)  HT Mode: VHT80
          Center Channel 1: 42 2: unknown
          Tx-Power: 0 dBm  Link Quality: unknown/70
          Signal: unknown  Noise: -110 dBm
          Bit Rate: unknown
          Encryption: unknown
          Type: nl80211  HW Mode(s): 802.11ac/n
          Hardware: embedded [Qualcomm Atheros IPQ4019]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy1

phy1-ap1.80 ESSID: unknown
          Access Point: DE:15:C8:3C:F8:07
          Mode: Master (VLAN)  Channel: 36 (5.180 GHz)  HT Mode: VHT80
          Center Channel 1: 42 2: unknown
          Tx-Power: 0 dBm  Link Quality: unknown/70
          Signal: unknown  Noise: -110 dBm
          Bit Rate: unknown
          Encryption: unknown
          Type: nl80211  HW Mode(s): 802.11ac/n
          Hardware: embedded [Qualcomm Atheros IPQ4019]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy1

as you can see, the vlan interfaces are there, they are just not part of the vlan list and therefore not picked up by luci

thx

Not seeing hotplug events for hardware NICs being detected

I'm trying to add support for remapping interfaces per ucidef_set_network_device_path for interfaces not marked "required for boot" in netdevices.mk (and therefore not present during preinit phase). This is most network interfaces.

I was going to add a generic hotplug script to handle the device creation events, but I only see add events for software interfaces (loopback, dummy, xfrm, etc.).

Please add support for regular hardware events as well.

Hotplug arsenal is incomplete

I've developed my own firewall script, which needs to read the addresses from pppoe-wan (that works sufficiently) and br-lan. I'm getting only an ifup event for br-lan. I need to act on the assignment of an IPv6 global address to br-lan.

For now, I'm using a /40 address in my script, but I'd rather use the assigned /60 address. While hotplug is designed to generate ifupdate events, they are only generated for the wan interface. wan_6 is missing, too.

Is there any chance to add more hotplug events to OpenWRT?

I've posted this question in the forum and made some progress with the help of brada4, but we both lack insight into the current mechanism that generates hotplug events. I found some hints to a transition to procd, but nothing pointing to specific code.

I'm willing to contribute, but I need pointers to the places in the code that could use some love.

It was suggested to me that this should not be an enhancement request but filed against netifd. I politely disagree because I found some mentions of procd being involved in hotplug events. But the entire hotplug generation mechanism is unclear to me and I have yet to find somebody or some document who/that explains that. So here we are...

netifd: WARNING

Tue Mar 26 17:42:59 2024 daemon.notice netifd: radio0 (20769): WARNING: Variable 'data' does not exist or is not an array/object
Tue Mar 26 17:42:59 2024 daemon.notice netifd: radio1 (20770): WARNING: Variable 'data' does not exist or is not an array/object

Just fresh started 23.05.3. Seen during /etc/init.d/network restart

No pppoe connect possible

The netifd commits from December 2023 break my pppoe connection to Deutsche Telekom AG. The connection is established and IP if set, but default route is not added. Looks like netifd crashes silently when the connection is established. Going back to the netifd version from November, 14th (before udebug was added) fixes this issue. The only difference that I can see in the logs is that the new version reports netifd: Network device 'pppoe-wan' link is down immediately after the connection was established while the older version does more stuff.

Logs of December version (failing):

Tue Dec 19 10:13:47 2023 daemon.notice pppd[9104]: PAP authentication succeeded
Tue Dec 19 10:13:47 2023 daemon.notice pppd[9104]: peer from calling number XXX authorized
Tue Dec 19 10:13:47 2023 daemon.notice ttyd[4973]: [2023/12/19 10:13:47:7076] N: rops_handle_POLLIN_netlink: DELADDR
Tue Dec 19 10:13:47 2023 daemon.notice pppd[9104]: local  IP address XXX
Tue Dec 19 10:13:47 2023 daemon.notice pppd[9104]: remote IP address XXX
Tue Dec 19 10:13:47 2023 daemon.notice pppd[9104]: primary   DNS address XXX
Tue Dec 19 10:13:47 2023 daemon.notice pppd[9104]: secondary DNS address XXX
Tue Dec 19 10:13:47 2023 daemon.notice pppd[9104]: local  LL address XXX
Tue Dec 19 10:13:47 2023 daemon.notice pppd[9104]: remote LL address XXX
Tue Dec 19 10:13:47 2023 daemon.notice netifd: Network device 'pppoe-wan' link is up
Tue Dec 19 10:13:47 2023 daemon.notice netifd: Network device 'pppoe-wan' link is down

root@rpi4-01:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
62.155.242.194  *               255.255.255.255 UH    0      0        0 pppoe-wan
192.168.178.0   *               255.255.254.0   U     0      0        0 br-lan

Logs of november version (working):

Tue Dec 19 10:15:55 2023 daemon.notice pppd[5140]: PAP authentication succeeded
Tue Dec 19 10:15:55 2023 daemon.notice pppd[5140]: peer from calling number XXX authorized
Tue Dec 19 10:15:56 2023 daemon.notice ttyd[5248]: [2023/12/19 10:15:56:0777] N: rops_handle_POLLIN_netlink: DELADDR
Tue Dec 19 10:15:56 2023 daemon.notice pppd[5140]: local  IP address XXX
Tue Dec 19 10:15:56 2023 daemon.notice pppd[5140]: remote IP address XXX
Tue Dec 19 10:15:56 2023 daemon.notice pppd[5140]: primary   DNS address XXX
Tue Dec 19 10:15:56 2023 daemon.notice pppd[5140]: secondary DNS address XXX
Tue Dec 19 10:15:56 2023 daemon.notice pppd[5140]: local  LL address XXX
Tue Dec 19 10:15:56 2023 daemon.notice pppd[5140]: remote LL address XXX
Tue Dec 19 10:15:56 2023 daemon.notice netifd: Network device 'pppoe-wan' link is up
Tue Dec 19 10:15:56 2023 daemon.notice netifd: Interface 'wan6' is enabled
Tue Dec 19 10:15:56 2023 daemon.notice netifd: Network alias 'pppoe-wan' link is up
Tue Dec 19 10:15:56 2023 daemon.notice netifd: Interface 'wan6' has link connectivity
Tue Dec 19 10:15:56 2023 daemon.notice netifd: Interface 'wan6' is setting up now
Tue Dec 19 10:15:56 2023 daemon.notice netifd: Interface 'wan' is now up

root@rpi4-01:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         p3e9bf2c2.dip0. 0.0.0.0         UG    0      0        0 pppoe-wan
62.155.242.194  *               255.255.255.255 UH    0      0        0 pppoe-wan
116.203.70.106  p3e9bf2c2.dip0. 255.255.255.255 UGH   0      0        0 pppoe-wan
192.168.178.0   *               255.255.254.0   U     0      0        0 br-lan

netifd: not bringing up tunnel interface with NO_DEVICE

Describe the bug

Randomly, changing some configuration parameters or creating a 6in4 or wireguard interface leads to netifd not being able to bring up the interface when running ifup, with ifstatus returning NO_DEVICE.

OpenWrt version

r23497-6637af95aa

OpenWrt release

23.05.0

OpenWrt target/subtarget

ramips/mt7621

Device

UniElec U7621-06 (16M flash)

Image kind

Official downloaded image

Steps to reproduce

Config:

config interface 'wan6'
        option proto '6in4'
        option peeraddr 'xxx.xxx.xxx.xxx'
        option ip6addr '2a0e:97c0:38f:fffd::1/64'
        list ip6prefix '2a0e:97c0:38f::/64'
        option ip6assign '64'
        option mtu '1472'
        option ipaddr 'yyy.yyy.yyy.yyy'
        option ttl '255'

Debug config in /etc/init.d/network:

start_service() {
        init_switch

        procd_open_instance
        procd_set_param command /sbin/netifd -l 5 -d 15
        procd_set_param stdout 1
        procd_set_param stderr 1
        procd_set_param respawn
        procd_set_param watch network.interface
        [ -e /proc/sys/kernel/core_pattern ] && {
                procd_set_param limits core="unlimited"
        }
        procd_close_instance
}

Logs (no errors or debug-level logs strangely):

Sun Feb 11 17:42:59 2024 daemon.err netifd[1493]: device_apply_config(1188): Device 'br-lan': config applied
Sun Feb 11 17:42:59 2024 daemon.err netifd[1493]: interface_update(1402): Update interface 'loopback'
Sun Feb 11 17:42:59 2024 daemon.err netifd[1493]: interface_update(1402): Update interface 'lan'
Sun Feb 11 17:42:59 2024 daemon.err netifd[1493]: interface_add_dns_server(1435): Add IPv4 DNS server: 192.168.69.1
Sun Feb 11 17:42:59 2024 daemon.err netifd[1493]: interface_update(1402): Update interface 'wan'
Sun Feb 11 17:42:59 2024 daemon.err netifd[1493]: interface_update(1402): Update interface 'wan6'
Sun Feb 11 17:42:59 2024 daemon.err netifd[1493]: interface_update(1402): Update interface 'wg_securebit'
Sun Feb 11 17:42:59 2024 daemon.err netifd[1493]: wdev_update(754): Update wireless device 'radio0'
Sun Feb 11 17:42:59 2024 daemon.err netifd[1493]: wdev_update(754): Update wireless device 'radio1'

Creating the interface through luci yields the same result.

Actual behaviour

Running ifup does not create the iface, with ifstatus returning NO_DEVICE.

Same thing happens when restarting the interface through luci, even across reboots.

Deleting and recreating the config of the same exact interface a few times fixes.

Expected behaviour

The interface gets created correctly.

Additional info

No response

Diffconfig

No response

Terms

I am reporting an issue for OpenWrt, not an unsupported fork.

network_find_wan returns interfaces with non-default ip4table

Describe the bug

The network_find_wan function uses the following query to find the WAN interface: [@.route[@.target='0.0.0.0' && [email protected]]].interface. If I parse it correctly, it's supposed to find the interfaces that have a route to 0.0.0.0, and this route is in the main table (i.e. no table override is set), which makes sense to me.

However, the [email protected] part of the query seems to be a no-op, because table is missing even for routes of the interfaces that use option ip4table in /etc/config/network. That means, network_find_wan will find such interfaces, although their 0.0.0.0 route is not in the main routing table. Many packages use network_find_wan to find the actual WAN interface, and they will misbehave if network_find_wan returns a VPN interface instead of WAN.

The same issue affects network_find_wan6.

OpenWrt version

r23246-d85013460d

OpenWrt target/subtarget

mediatek/mt7622

Device

Linksys E8450 (UBI) (actually Belkin RT3200)

Image kind

Self-built image

Steps to reproduce

Configuration (mind the ...):

/etc/iproute2/rt_tables:

...
1 vpn

/etc/config/network:

...
config interface 'vpn'
        option proto 'wireguard'
        option private_key '...'
        list addresses '...'
        list addresses '...'
        option ip4table 'vpn'
        option ip6table 'vpn'
        option nohostroute '1'

config wireguard_vpn
        option public_key '...'
        option preshared_key '...'
        option endpoint_host '...'
        option endpoint_port '...'
        option route_allowed_ips '1'
        option persistent_keepalive '25'
        list allowed_ips '0.0.0.0/0'
        list allowed_ips '::/0'
...

Check that the routes don't have the table field:

$ ifstatus vpn | jsonfilter -e "@.route[@]"
{ "target": "::", "mask": 0, "nexthop": "::", "source": "::\/0" }
{ "target": "0.0.0.0", "mask": 0, "nexthop": "0.0.0.0", "source": "0.0.0.0\/0" }

Check that the default route of vpn is not in the main routing table:

$ ip route | grep '^default '
default via ... dev wan ...

Check that the default route of vpn is in the vpn routing table:

$ ip route show table vpn | grep '^default '
default dev vpn proto static scope link

Check that network_find_wan returns vpn instead of wan:

$ . /lib/functions/network.sh
$ network_find_wan wan; echo "$wan"
vpn

Actual behaviour

network_find_wan returns vpn, although the vpn interface doesn't have a default route in the main table.

Expected behaviour

network_find_wan should return wan. ifstatus vpn should return the "table": "vpn" field for each route.

Additional info

I believe the root cause might be in netifd, because it generates data for the ifstatus output, but I didn't dig into netifd's sources.

Diffconfig

No response

Terms

I am reporting an issue for OpenWrt, not an unsupported fork.

option to skip creating default rule to subnet when using ip4table / ip6table

im setting up a vpn to pass all traffic trough it. to do that, im using ip4table and ip6table to create a route table for vpn outbound on wan only. and kept default route table have only vpn route.

but netifd will create route rule 10000 (local addresses as source) and 20000 (local subnets as destination) to the interface which using ip4/6table. and that make my traffic directly passed to wan without going through vpn when accessing address on wan subnet. which is not intended

i know the purpose of these rule is make subnet able to access even it not on the default route table. but it broke my custom rule and decreased flexibility. could you add a option to disable that? just like nohostroute option for wireguard

netifd: protocol script can't normally start more than one demon process

Description

I was writing protocol script for netifd and had a trouble managing two daemon processes for the same interface.
When multiple proc_run_command functions are invoked, each one terminates previously spawned process and starts new one.

Example

Use case can be found there along with a nasty workaround.

23.05 Wrong route subnet calculation

Describe the bug

UCI, network:

config route
        option interface 'eth3_mgnt'
        option target '172.16.0.0/12'
        option gateway '10.20.30.41'

results to:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
172.0.0.0       10.20.30.41     255.240.0.0     UG    0      0        0 eth3

OpenWrt version

r23497-6637af95aa

OpenWrt target/subtarget

x86/64

Device

AMI Corporation Aptio CRB

Image kind

Official downloaded image

Steps to reproduce

Add a route to 172.16.0.0/12 via UCI or LUCI

Actual behaviour

actually, the result is a route to 172.0.0.0/12 instead of 172.16.0.0/12

Expected behaviour

No response

Additional info

I'm sure, this bug comes with one of the latest updates because I had already installed 23.05 with functional routing

Diffconfig

No response

Terms

I am reporting an issue for OpenWrt, not an unsupported fork.

Upgrade from 2023-11-07-516ab774-1 to 2023-11-10-35facc83-1 causes routing issues

Remote routed networks using Wireguard has their network addresses modified when doing the upgrade on openwrt 23.05.0

netifd 2023-11-07-516ab774-1:

root@OpenWrt:~# ip r s dev private_dmz
10.33.1.0/24 dev private_dmz scope link  src 10.33.1.1 
10.33.1.5 dev private_dmz scope link 
10.33.1.6 dev private_dmz scope link 
10.33.1.10 dev private_dmz scope link 
10.81.15.0/24 dev private_dmz scope link 
192.168.1.0/24 dev private_dmz scope link 
192.168.11.0/24 dev private_dmz scope link

netifd 2023-11-10-35facc83-1:

root@OpenWrt:~# ip r s dev private_dmz
0.81.15.0/24 dev private_dmz scope link 
0.168.1.0/24 dev private_dmz scope link 
0.168.11.0/24 dev private_dmz scope link 
10.33.1.0/24 dev private_dmz scope link  src 10.33.1.1 
10.33.1.5 dev private_dmz scope link 
10.33.1.6 dev private_dmz scope link 
10.33.1.10 dev private_dmz scope link

The candicates of `proto_add_host_dependency` should be OR'd instead of AND'd

Most VPN protocols implemented by OpenWRT use proto_add_host_dependency to enforce the presence of a route to the endpoint as shown in https://github.com/search?q=org%3Aopenwrt+proto_add_host_dependency+language%3AShell&type=code. In addition, resolveip is employed to resolve the endpoint's address if set as a domain. When the endpoint domain resolves to multiple IPs, many protocol implementations iterate over and use proto_add_host_dependency to add all IPs returned by resolveip. Examples are PPTP: https://github.com/openwrt/openwrt/blob/1a47ce5ff2f2db07fca8fc28801c0a78cbf19fe4/package/network/services/ppp/files/ppp.sh#L298-L301 and L2TP: https://github.com/openwrt/packages/blob/8bbc9c7d796fc4685c9839839bed3b057aa18397/net/xl2tpd/files/l2tp.sh#L33-L36

In the multi-IP case, the interface should be brought up when any one of the IPs is reachable, from what I understand. In other words, the IP list added by proto_add_host_dependency should be OR'd. However, its internal implementation appears to require all IPs in the list to be reachable simultaneously, i.e., the IPs are AND'd, which doesn't make much sense to me.

In my scenario, the VPN server is in a dual-stack network so its domain has both A and AAAA records. The VPN client (running OpenWRT) is v4-only and has the following setup:

config interface 'vpn'
	option proto 'l2tp'
	option username 'username'
	option password 'password'
	option ipv6 'auto'
	option server 'vpn.example.com'  # has both A and AAAA records

Both the A and AAAA records of example.com are added by proto_add_host_dependency in proto_l2tp_setup. Since the client is v4-only, there won't be a route to the v6 address so the L2TP interface is never brought up. The workaround I'm taking is to create a 4.vpn.example.com that has an A record only.

I believe this is a general issue and the internal behavior of proto_add_host_dependency should be fixed rather than adding hacks to protocol implementations.

Cc: @yousong

uci set network.lan.enabled=0 doesn't work

Setting enabled=0 doesn't work properly.
E.g. use an pc-engines apu1 with default configuration.

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'eth1'
	list ports 'eth2'

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option ipaddr '192.168.1.1'
	option netmask '255.255.255.0'
	option ip6assign '60'
	option enabled '0'

uci set network.lan.enabled=0
reload_config
sleep 3
ifstatus lan |grep '"up"'
	"up": true,

But it should be disabled.

Possible memleak in system_bridge_vlan_check ?

Describe the bug

Netifd version: 2023-02-25

Scenario: Plugging in and out ethernet cable causes netifd unreasonable memory grow when vlans configured, inspected via /proc/PID/status by vmRSS line.

Found function which might be the case in system-linux.c:

int system_bridge_vlan_check(struct device *dev, char *ifname)
{
    struct bridge_vlan_check_data data = {
        .check_dev = dev,
        .ifindex = if_nametoindex(ifname),
        .ret = -1,
        .pending = true,
    };
    static struct ifinfomsg ifi = {
        .ifi_family = AF_BRIDGE
    };
    static struct rtattr ext_req = {
        .rta_type = IFLA_EXT_MASK,
        .rta_len = RTA_LENGTH(sizeof(uint32_t)),
    };
    uint32_t filter = RTEXT_FILTER_BRVLAN;
    struct nl_cb *cb = nl_cb_alloc(NL_CB_DEFAULT);
    struct bridge_vlan *vlan;
    struct nl_msg *msg;
    int i;

    if (!data.ifindex)
        return 0;

    msg = nlmsg_alloc_simple(RTM_GETLINK, NLM_F_DUMP);

    if (nlmsg_append(msg, &ifi, sizeof(ifi), 0) ||
        nlmsg_append(msg, &ext_req, sizeof(ext_req), NLMSG_ALIGNTO) ||
        nlmsg_append(msg, &filter, sizeof(filter), 0))
        goto free;

    vlist_for_each_element(&dev->vlans, vlan, node) {
        struct bridge_vlan_hotplug_port *port;

        for (i = 0; i < vlan->n_ports; i++) {
            if (!strcmp(vlan->ports[i].ifname, ifname))
                vlan->ports[i].check = 0;
            else
                vlan->ports[i].check = -1;
        }

        list_for_each_entry(port, &vlan->hotplug_ports, list) {
            if (!strcmp(port->port.ifname, ifname))
                port->port.check = 0;
            else
                port->port.check = -1;
        }
    }

    nl_cb_set(cb, NL_CB_VALID, NL_CB_CUSTOM, bridge_vlan_check_cb, &data);
    nl_cb_set(cb, NL_CB_FINISH, NL_CB_CUSTOM, bridge_vlan_ack_cb, &data);
    nl_cb_set(cb, NL_CB_ACK, NL_CB_CUSTOM, bridge_vlan_ack_cb, &data);
    nl_cb_err(cb, NL_CB_CUSTOM, bridge_vlan_error_cb, &data);

    if (nl_send_auto_complete(sock_rtnl, msg) < 0)
        goto free;

    data.ret = 0;
    while (data.pending)
        nl_recvmsgs(sock_rtnl, cb);

    vlist_for_each_element(&dev->vlans, vlan, node) {
        struct bridge_vlan_hotplug_port *port;

        for (i = 0; i < vlan->n_ports; i++) {
            if (!vlan->ports[i].check) {
                data.ret = 1;
                break;
            }
        }

        list_for_each_entry(port, &vlan->hotplug_ports, list) {
            if (!port->port.check) {
                data.ret = 1;
                break;
            }
        }
    }

    goto out;

free:
    nlmsg_free(msg);
out:
    nl_cb_put(cb);
    return data.ret;
}

seems like this goto out; skips nlmsg_free(msg);

After removing 'goto out;' and testing, seems like vmRSS does not grow unreasonably, altought it grows and decreases, but stays more likely stable.

Is this intentional or a memory leak?

openwrt / netifd Goto Github PK

netifd's Issues

Describe the bug

OpenWrt version

OpenWrt release

OpenWrt target/subtarget

Device

Image kind

Steps to reproduce

Actual behaviour

Expected behaviour

Additional info

Diffconfig

Terms

Describe the bug

OpenWrt version

OpenWrt target/subtarget

Device

Image kind

Steps to reproduce

Actual behaviour

Expected behaviour

Additional info

Diffconfig

Terms

Description

Example

Describe the bug

OpenWrt version

OpenWrt target/subtarget

Device

Image kind

Steps to reproduce

Actual behaviour

Expected behaviour

Additional info

Diffconfig

Terms

Describe the bug

Recommend Projects

Recommend Topics

Recommend Org