I asked this question on the linux-wireless IRC channel last week but I don't think anyone was around at the time, so here it is over e-mail. We have a userlevel application that uses a netlink socket to figure out when networking interfaces on the system go up or down. It does so by looking at all RTM_NEWLINK messages that arrive on the socket and examining their ifi_flags fields. We interpret the presence of both IFF_UP and IFF_RUNNING to mean that an interface has gone up, while the lack thereof to mean that an interface is down. We've noticed that associating to a wireless access point generates several additional RTM_NEWLINK messages. These messages contain an attribute with type IFLA_WIRELESS which distinguishes them from the usual RTM_NEWLINK messages that indicate link up or link down. Originally, our application did not ignore these wireless events, but this led to a problem: we'd receive the events _after_ the IFF_UP|IFF_RUNNING message indicating link up, and the events' ifi_flags did _not_ contain IFF_RUNNING. This would mislead our application into thinking the interface was momentarily brought up, then quickly brought back down. Digging into the kernel code revealed that the wireless events generated by wireless_send_event aren't immediately delivered to userlevel; they are placed on the 'wireless_nlevent_work' workqueue to be processed asynchronously. At the same time, the usual RTM_NEWLINK message indicating link up (ieee80211_set_associated --> netif_carrier_on --> linkwatch_fire_event --> linkwatch_do_dev --> netdev_state_change) is processed synchronously. We think this could cause the wireless events to be delivered to userlevel after the link up message, confusing any userlevel applications that expect messages to be chronologically ordered. As I alluded to earlier, we've modified our application to ignore RTM_NEWLINK messages with IFLA_WIRELESS attributes, and this has fixed our problem. My question is: is this behavior indicative of a kernel bug? Or is it a known semantic of RTM_NEWLINK messages? -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
