> > There are two test scenarios: > > 1) When creating the path to a ta where the direct hop is a bad path. > > Relatively easy to setup and demonstrate poor performance pre-patch. > > 2) Incorrect routing when the metric for an existing SN is changed > > without also updating the SN. Hard to demonstrate. We've certainly > > seen similar bugs with our own mesh protocols but that was with > > protocols explicitly designed with testing support. Best approach is > > probably via something like http://alloy.mit.edu/alloy/ > > If the direct hop is a bad path, could it be due the metric calculation. Sure, metric calculations are not perfect. But that is an entirely separate can of worms. For the purposes of this discussion we can assume that the metrics are perfect. Simplest case is the one I mentioned before: a U where we're trying to route between the ends of the U but the direct hop is bad and the links along the U are excellent. > Also, you may also add your vendor specific mesh protocol to open source > community. Maybe. We spent many man years on it and eventually got it routing well. It was all done in a commercial setting though so I don't know that we would open source it. -- Jesse -- 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
