| Stefan Rompf | 3a01c1e | 2006-05-09 15:15:35 -0700 | [diff] [blame] | 1 |  | 
|  | 2 | 1. Introduction | 
|  | 3 |  | 
|  | 4 | Linux distinguishes between administrative and operational state of an | 
| Matt LaPlante | 3f6dee9 | 2006-10-03 22:45:33 +0200 | [diff] [blame] | 5 | interface. Administrative state is the result of "ip link set dev | 
| Stefan Rompf | 3a01c1e | 2006-05-09 15:15:35 -0700 | [diff] [blame] | 6 | <dev> up or down" and reflects whether the administrator wants to use | 
|  | 7 | the device for traffic. | 
|  | 8 |  | 
|  | 9 | However, an interface is not usable just because the admin enabled it | 
|  | 10 | - ethernet requires to be plugged into the switch and, depending on | 
|  | 11 | a site's networking policy and configuration, an 802.1X authentication | 
|  | 12 | to be performed before user data can be transferred. Operational state | 
|  | 13 | shows the ability of an interface to transmit this user data. | 
|  | 14 |  | 
|  | 15 | Thanks to 802.1X, userspace must be granted the possibility to | 
|  | 16 | influence operational state. To accommodate this, operational state is | 
|  | 17 | split into two parts: Two flags that can be set by the driver only, and | 
|  | 18 | a RFC2863 compatible state that is derived from these flags, a policy, | 
|  | 19 | and changeable from userspace under certain rules. | 
|  | 20 |  | 
|  | 21 |  | 
|  | 22 | 2. Querying from userspace | 
|  | 23 |  | 
|  | 24 | Both admin and operational state can be queried via the netlink | 
|  | 25 | operation RTM_GETLINK. It is also possible to subscribe to RTMGRP_LINK | 
|  | 26 | to be notified of updates. This is important for setting from userspace. | 
|  | 27 |  | 
|  | 28 | These values contain interface state: | 
|  | 29 |  | 
|  | 30 | ifinfomsg::if_flags & IFF_UP: | 
|  | 31 | Interface is admin up | 
|  | 32 | ifinfomsg::if_flags & IFF_RUNNING: | 
|  | 33 | Interface is in RFC2863 operational state UP or UNKNOWN. This is for | 
|  | 34 | backward compatibility, routing daemons, dhcp clients can use this | 
|  | 35 | flag to determine whether they should use the interface. | 
|  | 36 | ifinfomsg::if_flags & IFF_LOWER_UP: | 
|  | 37 | Driver has signaled netif_carrier_on() | 
|  | 38 | ifinfomsg::if_flags & IFF_DORMANT: | 
|  | 39 | Driver has signaled netif_dormant_on() | 
|  | 40 |  | 
|  | 41 | These interface flags can also be queried without netlink using the | 
|  | 42 | SIOCGIFFLAGS ioctl. | 
|  | 43 |  | 
|  | 44 | TLV IFLA_OPERSTATE | 
|  | 45 |  | 
|  | 46 | contains RFC2863 state of the interface in numeric representation: | 
|  | 47 |  | 
|  | 48 | IF_OPER_UNKNOWN (0): | 
|  | 49 | Interface is in unknown state, neither driver nor userspace has set | 
|  | 50 | operational state. Interface must be considered for user data as | 
|  | 51 | setting operational state has not been implemented in every driver. | 
|  | 52 | IF_OPER_NOTPRESENT (1): | 
|  | 53 | Unused in current kernel (notpresent interfaces normally disappear), | 
|  | 54 | just a numerical placeholder. | 
|  | 55 | IF_OPER_DOWN (2): | 
|  | 56 | Interface is unable to transfer data on L1, f.e. ethernet is not | 
|  | 57 | plugged or interface is ADMIN down. | 
|  | 58 | IF_OPER_LOWERLAYERDOWN (3): | 
|  | 59 | Interfaces stacked on an interface that is IF_OPER_DOWN show this | 
|  | 60 | state (f.e. VLAN). | 
|  | 61 | IF_OPER_TESTING (4): | 
|  | 62 | Unused in current kernel. | 
|  | 63 | IF_OPER_DORMANT (5): | 
|  | 64 | Interface is L1 up, but waiting for an external event, f.e. for a | 
|  | 65 | protocol to establish. (802.1X) | 
|  | 66 | IF_OPER_UP (6): | 
|  | 67 | Interface is operational up and can be used. | 
|  | 68 |  | 
|  | 69 | This TLV can also be queried via sysfs. | 
|  | 70 |  | 
|  | 71 | TLV IFLA_LINKMODE | 
|  | 72 |  | 
|  | 73 | contains link policy. This is needed for userspace interaction | 
|  | 74 | described below. | 
|  | 75 |  | 
|  | 76 | This TLV can also be queried via sysfs. | 
|  | 77 |  | 
|  | 78 |  | 
|  | 79 | 3. Kernel driver API | 
|  | 80 |  | 
|  | 81 | Kernel drivers have access to two flags that map to IFF_LOWER_UP and | 
|  | 82 | IFF_DORMANT. These flags can be set from everywhere, even from | 
|  | 83 | interrupts. It is guaranteed that only the driver has write access, | 
|  | 84 | however, if different layers of the driver manipulate the same flag, | 
|  | 85 | the driver has to provide the synchronisation needed. | 
|  | 86 |  | 
|  | 87 | __LINK_STATE_NOCARRIER, maps to !IFF_LOWER_UP: | 
|  | 88 |  | 
|  | 89 | The driver uses netif_carrier_on() to clear and netif_carrier_off() to | 
|  | 90 | set this flag. On netif_carrier_off(), the scheduler stops sending | 
|  | 91 | packets. The name 'carrier' and the inversion are historical, think of | 
|  | 92 | it as lower layer. | 
|  | 93 |  | 
|  | 94 | netif_carrier_ok() can be used to query that bit. | 
|  | 95 |  | 
|  | 96 | __LINK_STATE_DORMANT, maps to IFF_DORMANT: | 
|  | 97 |  | 
|  | 98 | Set by the driver to express that the device cannot yet be used | 
|  | 99 | because some driver controlled protocol establishment has to | 
|  | 100 | complete. Corresponding functions are netif_dormant_on() to set the | 
|  | 101 | flag, netif_dormant_off() to clear it and netif_dormant() to query. | 
|  | 102 |  | 
|  | 103 | On device allocation, networking core sets the flags equivalent to | 
|  | 104 | netif_carrier_ok() and !netif_dormant(). | 
|  | 105 |  | 
|  | 106 |  | 
|  | 107 | Whenever the driver CHANGES one of these flags, a workqueue event is | 
|  | 108 | scheduled to translate the flag combination to IFLA_OPERSTATE as | 
|  | 109 | follows: | 
|  | 110 |  | 
|  | 111 | !netif_carrier_ok(): | 
|  | 112 | IF_OPER_LOWERLAYERDOWN if the interface is stacked, IF_OPER_DOWN | 
|  | 113 | otherwise. Kernel can recognise stacked interfaces because their | 
|  | 114 | ifindex != iflink. | 
|  | 115 |  | 
|  | 116 | netif_carrier_ok() && netif_dormant(): | 
|  | 117 | IF_OPER_DORMANT | 
|  | 118 |  | 
|  | 119 | netif_carrier_ok() && !netif_dormant(): | 
|  | 120 | IF_OPER_UP if userspace interaction is disabled. Otherwise | 
|  | 121 | IF_OPER_DORMANT with the possibility for userspace to initiate the | 
|  | 122 | IF_OPER_UP transition afterwards. | 
|  | 123 |  | 
|  | 124 |  | 
|  | 125 | 4. Setting from userspace | 
|  | 126 |  | 
|  | 127 | Applications have to use the netlink interface to influence the | 
|  | 128 | RFC2863 operational state of an interface. Setting IFLA_LINKMODE to 1 | 
|  | 129 | via RTM_SETLINK instructs the kernel that an interface should go to | 
|  | 130 | IF_OPER_DORMANT instead of IF_OPER_UP when the combination | 
|  | 131 | netif_carrier_ok() && !netif_dormant() is set by the | 
|  | 132 | driver. Afterwards, the userspace application can set IFLA_OPERSTATE | 
|  | 133 | to IF_OPER_DORMANT or IF_OPER_UP as long as the driver does not set | 
|  | 134 | netif_carrier_off() or netif_dormant_on(). Changes made by userspace | 
|  | 135 | are multicasted on the netlink group RTMGRP_LINK. | 
|  | 136 |  | 
|  | 137 | So basically a 802.1X supplicant interacts with the kernel like this: | 
|  | 138 |  | 
|  | 139 | -subscribe to RTMGRP_LINK | 
|  | 140 | -set IFLA_LINKMODE to 1 via RTM_SETLINK | 
|  | 141 | -query RTM_GETLINK once to get initial state | 
|  | 142 | -if initial flags are not (IFF_LOWER_UP && !IFF_DORMANT), wait until | 
|  | 143 | netlink multicast signals this state | 
|  | 144 | -do 802.1X, eventually abort if flags go down again | 
|  | 145 | -send RTM_SETLINK to set operstate to IF_OPER_UP if authentication | 
|  | 146 | succeeds, IF_OPER_DORMANT otherwise | 
|  | 147 | -see how operstate and IFF_RUNNING is echoed via netlink multicast | 
|  | 148 | -set interface back to IF_OPER_DORMANT if 802.1X reauthentication | 
|  | 149 | fails | 
|  | 150 | -restart if kernel changes IFF_LOWER_UP or IFF_DORMANT flag | 
|  | 151 |  | 
|  | 152 | if supplicant goes down, bring back IFLA_LINKMODE to 0 and | 
|  | 153 | IFLA_OPERSTATE to a sane value. | 
|  | 154 |  | 
|  | 155 | A routing daemon or dhcp client just needs to care for IFF_RUNNING or | 
|  | 156 | waiting for operstate to go IF_OPER_UP/IF_OPER_UNKNOWN before | 
|  | 157 | considering the interface / querying a DHCP address. | 
|  | 158 |  | 
|  | 159 |  | 
|  | 160 | For technical questions and/or comments please e-mail to Stefan Rompf | 
|  | 161 | (stefan at loplof.de). |