Netifd interaction with Various Driver

For Developers
#1

I have been working on adding a new device to the list.
While planning my tasks was not sure if I should make
device specific changes to netifd. If anyone has an idea
on how it works, please share it.
My doubts are like how does netifd interact with the wireless driver
and apply changes if there is some config change like SSID name change
to the driver. Is there any platform specific changes that needs to be taken care of?

1 Like
#2

Do the wireless "chips" already have driver support in the OpenWRT tree?

#3

Unless the wireless driver in question conforms to mac80211/cfg80211, it needs to ship an /lib/wifi/*.sh helper file which takes care of translating the netifd/uci configuration requests into hardware specific settings.

Such a helper shell file needs to provide a number of procedures adhering to a specific naming convention.

The xxx placeholder should be replaced with a driver backend nickname. OpenWrt historically used atheros for the proprietary madwifi driver, broadcom for the proprietary wl driver and mac80211 for all Linux wireless drivers conforming to the Linux cfg80211 api.

Procedures that should be implemented by the helper are:

  • detect_xxx() - discover the radio hardware and produce suitable default configuration
    • Invoked by /sbin/wifi config through hotplug
    • The function should be idempotent, if discovered hardware already is present in the config, no further configuration should be emitted.
    • Receives no arguments.
  • scan_xxx() - preparation work for enable_xxx() and disable_xxx()
    • A bit misleadingly named; its purpose is to prepare state information and query hardware details in preparation to the subsequent call of disable_xxx() or enable_xxx()
    • Called by /sbin/wifi up [radioname], /sbin/wifi down [radioname], /sbin/wifi reload [radioname] which is usually invoked automatically by netifd.
    • If you do not need any context specific preparation, supply a no-op shell procedure
    • Receives the config wifi-device section name (as produced by detect_xxx()) as sole argument.
  • enable_xxx() - translate the /etc/config/wireless settings into specific hardware configuration and bring up all configured SSIDs
    • Receives the config wifi-device section name (as produced by detect_xxx()) as sole argument
    • Invoked by /sbin/wifi up [radioname] and /sbin/wifi reload [radioname]
    • This is the central place where /etc/config/wireless should be read and turned into driver specific settings
  • disable_xxx() - deconfigure all SSIDs, stop beaconing and shut down the radio
    • Receives the config wifi-device section name (as produced by detect_xxx()) as sole argument
    • Invoked by /sbin/wifi down [radioname] and /sbin/wifi reload [radioname]
    • This function shall properly deconfigure the radio so that a subsequent enable_xxx() call can work off a clean state

In addition, the shell helper file should contain a single statement append DRIVERS "xxx" which will register the xxx driver type with netifd/uci.

You can find an example implementation of a non-standard wireless driver helper at https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/kernel/broadcom-wl/files/lib/wifi/broadcom.sh.

The helper script is driven by /sbin/wifi at https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/base-files/files/sbin/wifi.

2 Likes
#5

Thankyou for the reply. This helped a lot.
What about ethernet drivers? How does it communicate with netifd? Is there platform specific changes needed?

#6

No the chips do not have support in the Openwrt tree. But it confirms to mac80211.

#7

Now I'm getting curious, which device(s) ??

#8

No, you usually do not need any specific handling for ethernet drivers with netifd. As long as iproute2 works as usual, netifd will work too.

If you wifi driver is fully cfg80211 conformant then you do not need a helper script for netifd either, it should work ootb then.

#9

its a mediatek device

#10

Thankyou for the reply.

#11

So you want to use mt7610 or mt7612u, I assume.
Maybe also from one of my repositories, which you can find easily.
My advice please don't
The driver is unstable and will crash occasionally, mostly in the mcu/mf code, which needs some big rework