openwrt / netifd Goto Github PK

View Code? Open in Web Editor NEW

16.0 28.0 16.0 1.05 MB

[MIRROR] OpenWrt Network interface configuration daemon

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

CMake 0.35% C 96.35% Shell 3.29%

netifd's People

Stargazers

Watchers

Forkers

hauke virtuald rthakur33 dangowrt madnessasap zhao-wuji-ahh oldium ansuel devdevdany mikma seanpm2001 kiddin9 brada4 systemcrash mhusaam g10h4ck

netifd's Issues

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

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.

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.

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.

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.

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?

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

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.

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 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

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: 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

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?

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

openwrt / netifd Goto Github PK

netifd's People

Stargazers

Watchers

Forkers

netifd's Issues

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

OpenWrt version

OpenWrt target/subtarget

Device

Image kind

Steps to reproduce

Actual behaviour

Expected behaviour

Additional info

Diffconfig

Terms

Description

Example

Describe the bug

Recommend Projects

Recommend Topics

Recommend Org