Am Dienstag 15 November 2005 15:16 schrieb jamal: > Having said that, perhaps thats where the concept of useroverride you > have or IFF_WAIT needs to go. What should be done though is to select an > "operational" mode via admin flags - example "the device is set by the > admin to dormant state" or "the device is set to dial-on-demand mode" > etc.
And that's mostly what Thomas wants to do - but now let's look at a race condition that makes IFF_WAIT needed. Example is 802.1X over ethernet. For ethernet, we know that the driver won't call netif_dormant_on/off(). Let's see what happens when the link beat on an existing ethernet connection is lost for a short time: Without 802.1X: -Link beat lost -netif_carrier_off() by driver -> maps to OPER_DOWN -link beat comes back -netif_carrier_on() by driver -> maps to OPER_UP With 802.1X, userspace supplicant is fast enough to follow: -Link beat lost -netif_carrier_off() by driver -> maps to OPER_DOWN -supplicant reads netlink notification -netif_dormant_on() by supplicant -> still maps to OPER_DOWN -link beat comes back -netif_carrier_on() by driver -> maps to OPER_DORMANT -supplicant reads netlink messages, successfully authenticates via 802.1X -netif_dormant_off() by supplicant -> OPER_UP With 802.1X, userspace supplicant cannot follow: -Link beat lost -netif_carrier_off() by driver -> maps to OPER_DOWN -link beat comes back -netif_carrier_on() by driver -> maps to OPER_UP, even though it should be OPER_DORMANT now! -supplicant reads notifications -netif_dormant_on() by supplicant -> maps to OPER_DORMANT -Rest as above As you see, we report a wrong OPER_UP here. For Thomas' suggestion, IFF_WAIT avoids this. I use OPERU_UP_UNTIL_DORMANT for the same purpose. Stefan - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
