| Both sides previous revision Previous revision Next revision | Previous revision |
| docs:techref:netifd [2018/11/14 15:41] – [Why do we want netifd?] ldir | docs:techref:netifd [2023/10/06 04:17] (current) – update links vgaetera |
|---|
| * some scripts in ''/etc/hotplug.d''.) | * some scripts in ''/etc/hotplug.d''.) |
| |
| ''netifd'' is intended to stay compatible with the existing format of ''[[docs:guide-user:base-system:basic-networking|/etc/config/network]]'', the only exceptions being rare special cases like | ''netifd'' is intended to stay compatible with the existing format of ''[[docs:guide-user:network:network_configuration|/etc/config/network]]'', the only exceptions being rare special cases like |
| aliases or the overlay variables in ''/var/state'' (though even most of those can be easily emulated). | aliases or the overlay variables in ''/var/state'' (though even most of those can be easily emulated). |
| | |
| | ==== Debugging ==== |
| | |
| | * Add the switch ''-l <level>'' to ///etc/init.d/network// |
| | * Level is specified as an integer: |
| | * 1 = L_CRIT |
| | * 2 = L_WARNING |
| | * 3 = L_NOTICE (default) |
| | * 4 = L_INFO |
| | * 5 = L_DEBUG |
| | * For the L_DEBUG level, there is another option ''-d <mask>'' to set a mask: |
| | * Options are: |
| | * 1 = DEBUG_SYSTEM |
| | * 2 = DEBUG_DEVICE |
| | * 4 = DEBUG_INTERFACE |
| | * 8 = DEBUG_WIRELESS |
| | * Add your favorite options together to obtain the ''<mask>''. |
| | |
| | * In order for the output to be seen you'll need to modify /etc/init.d/network to add: |
| | * procd_set_param stdout 1 |
| | * procd_set_param stderr 1 |
| | * to start_service so that procd doesn't send netifd hotplug script output to /dev/null. |
| |
| ==== Help with the development of netifd ==== | ==== Help with the development of netifd ==== |
| |
| ==== Why do we want netifd? ==== | ==== Why do we want netifd? ==== |
| One thing that ''netifd'' does much better then old //OpenWrt-network configuration scripts// is handling configuration changes. With ''netfid'', when the file ''[[docs:guide-user:base-system:basic-networking|/etc/config/network]]'' changes, you no longer have to restart all interfaces. Simply run **''/etc/init.d/network reload''**. This will issue an ''ubus''-call to ''netifd'', telling it to figure out the difference between runtime state and the new config and apply only that. This works on a per-interface level, even with protocol handlers written as shell scripts. | One thing that ''netifd'' does much better then old //OpenWrt-network configuration scripts// is handling configuration changes. With ''netifd'', when the file ''[[docs:guide-user:network:network_configuration|/etc/config/network]]'' changes, you no longer have to restart all interfaces. Simply run **''/etc/init.d/network reload''**. This will issue an ''ubus''-call to ''netifd'', telling it to figure out the difference between runtime state and the new config and apply only that. This works on a per-interface level, even with protocol handlers written as shell scripts. |
| |
| It boils down to the fact that the current network and interface setup mechanisms (via network configuration scripts) are rather constrained and inflexible: | It boils down to the fact that the current network and interface setup mechanisms (via network configuration scripts) are rather constrained and inflexible: |
| |
| ''Netifd'' will be able to manage even complex interface configurations with a mix of bonding, vlans, bridges, etc. and handle the dependencies | ''Netifd'' will be able to manage even complex interface configurations with a mix of bonding, vlans, bridges, etc. and handle the dependencies |
| between interfaces properly - and of course all that without adding unnecessary bloat. AFAIK there are no alternatives to netifd, e.g. [[https://connman.net/|connman]] seems to be centered around one specifific use case only: having a mobile device access the internet through multiple connections. | between interfaces properly - and of course all that without adding unnecessary bloat. \\ |
| | AFAIK there are no alternatives to netifd, e.g. [[https://connman.net/|connman]] seems to be centered around one specifific use case only: having a mobile device access the internet through multiple connections. Connman is based on dbus. |
| |
| The following is a brief conversation from IRC regarding hints on how netifd is involved with wifi interface startup and variables used. It 'documents' my frustration with trying to add a new uci variable (utf8_ssid), and I don't think the answers contained should be lost: | The following is a brief conversation from IRC regarding hints on how netifd is involved with wifi interface startup and variables used. It 'documents' my frustration with trying to add a new uci variable (utf8_ssid), and I don't think the answers contained should be lost: |
| |
| [20:20:06] <jow> ldir: its complicated | <code>[20:20:06] <jow> ldir: its complicated |
| [20:20:29] <jow> ldir: upon start, netifd scans all wireless handlers in /lib/netifd/wireless/ | [20:20:29] <jow> ldir: upon start, netifd scans all wireless handlers in /lib/netifd/wireless/ |
| [20:21:08] <jow> ldir: so for mac80211 that'd be /lib/netifd/wireless/mac80211.sh | [20:21:08] <jow> ldir: so for mac80211 that'd be /lib/netifd/wireless/mac80211.sh |
| [20:39:19] <ldir> jow: in theory I've done that - I noticed mac80211.sh has a 'common' set options | [20:39:19] <ldir> jow: in theory I've done that - I noticed mac80211.sh has a 'common' set options |
| [20:39:36] <jow> you most likely need to restart netifd for it to become aware of the new option | [20:39:36] <jow> you most likely need to restart netifd for it to become aware of the new option |
| [20:39:50] <jow> du to the uci->blob->json->string->jshn call chain | [20:39:50] <jow> du to the uci->blob->json->string->jshn call chain</code> |
| |
| |
| |
| |