* Stefan Rompf <[EMAIL PROTECTED]> 2005-11-07 20:25 > dose:~ # ip addr add 192.168.200.1/24 dev eth1 > dose:~ # ip link set eth1 up > dose:~ # ifconfig eth1 | fgrep UP > UP BROADCAST MULTICAST MTU:1500 Metric:1 > dose:~ # ip route show 192.168.200.0/24 > 192.168.200.0/24 dev eth1 proto kernel scope link src 192.168.200.1 > dose:~ # ping 192.168.200.10 > PING 192.168.200.10 (192.168.200.10) 56(84) bytes of data. > From 192.168.200.1: icmp_seq=2 Destination Host Unreachable > dose:~ # arp > 192.168.200.10 (incomplete) eth1 > > Even though the interface is not IFF_RUNNING and queueing is therefore > disabled, the kernel created a route pointing to it and uses it.
Yes, just like it is supposed to do. > > Isn't it the routing daemon's fault when preferring a route > > which has the IFF_RUNNING flag cleared? I'm sorry fot not getting it. ;-) > > As the kernel maintains this connected route, userspace is IMHO not > responsible. Quagga could add its routes with a higher metric (administrative > distance in cisco terms), kernel should use them as soon as the connected > route becomes unavailable due to carrier failure (or dormant for wireless > interfaces). Then how are you going to implement OSPF which has its own link state detection? It's basically the same just that checking the carrier is a very weak solution. The routes, especially the local routes, must exist while there is no carrier. > Btw, adding a userspace workaround would be dangerous. If the routing daemon > crashes while a link is down, the userspace removed connected route would not > come back, leaving the router unreachable on this interface. *Very* bad. I think this is a very weak excuse to move something into the kernel that can exist in userspace. The routing daemon has to check the interfaces on start-up eventually bringing up interfaces so all you have to make sure is that it doesn't crash all the time and that you supervise the process somehow. > > The reason we now have netif_carrier_* instead of |= IFF_RUNNING as it > > used to be is exactly atomicty. Since you write to oper_state from > > various locations the operation must be atomic to avoid corruption. > > No, it's because the IFF_* flags are a bit field that can only be changed > from > process context protected by rtnl/dev_base_lock, different to > __LINK_STATE_NO_CARRIER (or a operational state field) that must be > accessible from interrupts. I'm not sure about what exactly you're argueing. Using a char for the operational state may imply bit operations on some architectures. There goes your atomicity. dev->flags is certainly not protected by dev_base_lock, I'm not even sure if the rtnl semaphore is acquired for all write accesses to dev->flags. > > > No, !netif_running() is ADMIN down, mostly representing the IFF_UP flag. > > > > Right but the RFC specifies that admin. down implies operational down: > > Indeed, but we should not set OPER_DOWN if and only if admin is down ;-) So you mean we should not follow the RFC in this case? What operational status would it be then? OPER_UNKNOWN? > > This also describes why your scheme cannot work, we have to memorize > > the status of for example carrier state. > > Can't see that requirement from RFC, and devices are normally initialized in > their open()-"methods". It's an SNMP RFC, it's not supposed to tell us how to manage interface states in the kernel. The carrier state is event driven, which means that when we don't memorize this information while we announce the interface as down we'd have to ask the drivers about the carrier state when we put it up again which is just non-sense. I have a hard time seeing you first not following the RFC and then relying on it like it would be the overall perfect solution. > Ok, so I hope a finally managed to make my point clear about the different > dormant states ;-) I understand your idea but I don't agree. - 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
