Stefan Rompf <[EMAIL PROTECTED]> writes: > But what happens when the link from (2) to (C) fails? The routing protocol > would realize it (actually it was me how has added IFF_RUNNING support to > quagga) and add a route to (C) via (3) on (B). However, the "connected" > route > would still have precedence and the linux IP stack on (2) would happily try > to continue using the broken link to (C), even if we add juju magic to the > link layer to recognize and drop L3 packets.
Linux should just IMHO drop direct route when !IFF_RUNNING. Another thing is if you have quagga (never used it, but I done things like that with mrtd and even without IFF_RUNNING I think) you can configure /32 mask on the managed interface and let quagga add dynamic routes. That's what quagga and not the kernel is for - dynamic routing, right? > OPER_DORMANTL3UP is another beast. Dial on demand interfaces may be dormant, > but of course layer L3 must consider routes pointing to them, or they would > never dial. I'm not entirely against L3DOWN/UP idea. Normally dial-up devices show IFF_RUNNING and the internal state is not visible. I would rather do it with another flag (and another patch, when they are users), signaling that the device isn't yet connected even if it's IFF_RUNNING. > OTOH, we don't need to be completely atomic as the netif_carrier_*-functions > already require driver controlled synchronisation. We can't assume anything like this. > We just need to make sure > that the caches are coherent before linkwatch kernel thread runs. wmb() is for gcc and bus reordering etc, not needed here. > Bad > problem > here: To allow software/userspace controlled probe and association packets, > wireless devices must not go to netif_carrier_off() anymore when the > association is lost I'm told it doesn't seem a problem not limitation at all, right? -- Krzysztof Halasa - 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
