想追踪一下associationControl类的customAssociationControl()方法的调用情况，
然后发现这个类associationControl里的这个方法customAssociationControl，仅在被初始化时被调用。
mininet/wifi/associationControl.py
class associationControl(object):
changeAP = False
def __init__(self, sta, ap, wlan, ac):
self.customAssociationControl(sta, ap, wlan, ac)
def customAssociationControl(self, sta, ap, wlan, ac):
pass所以直接追踪，associationControl类被初始化的地方就好了。记住是带四个参数的。
上图中带一个参数的那个方法是其他的类的方法，这里不管（碍视线，为什么不能命个别的名？）
知道带四个参数的是在mininet/wifi/mobility.py的L264。
进入之后，发现是在handover()方法中被调用的。（只有这一个地方哦！）
从代码中可以看出，associationControl()被执行的条件是：
AC不为空，sta正在关联的ap不为空（即当前是有ap与sta关联的），而且与传入的参数ap(即希望发生切换的ap)不是同一个。
那么handover()方法是在哪被调用的呢？
使用这个命令：
grep -rn "handover(" *|egrep -v "_handover"结果如下：
这里使用egrep -v "_handover"为了过滤掉很多带下划线的其他带”handover”字符串的方法。（注：图中的前三行和后三行的内容是一样的。）
最后发现其调用在：
1. mininet/wifi/mobility.py的check_association()方法。
可以看出在check_association()方法中handover()方法被执行的条件是：
sta与ap的距离<= ap的信号范围距离
mininet/wifi/net.py的auto_association()方法。
所以接下来就是要看这两个方法在哪里被调用的。
auto_association()方法
其中第一个auto_association()方法：在mininet/wifi/net.py的build()方法中（L723），条件是，allAutoAssociation=True，而且必须没有mobility的情况。因为我们的拓扑中关注的节点是具有mobility性质的，所以排除这条线。
auto_association()方法第二次(也是最后一次出现)是在mininet/wifi/net.py的build()方法中（L2080）的stopMobility()方法中被调用。
而总所周知，stopMobility()方法肯定要在仿真中被调用的。但是不理解为什么要在这里调用auto_association()方法。作者可能想的是：在移动结束之后再调用auto_association()方法，使得停下来的sta可以自动进行关联。但是这样好吗？
check_association()方法
最后两行，即是最调用的地方。即mininet/wifi/mobility.py的configureLinks()方法。
其中有一个是在parameters()方法中被调用，但是parameters()方法本身也没人调用它啊，所以parameters()方法这条线放弃了。
另外一个configureLinks()方法被调用的地方是：configLinks()方法中，注意别看错！
mininet/wifi/mobility.py的configLinks()方法
其中一个 configLinks()方法的调用出现在mininet/wifi/net.py
发现其实还是在auto_association()方法中，遂放弃。
其他的都在mininet/wifi/node.py中。
而在mininet/wifi/node.py中有很多地方都调用了。
比如setRange(),setPosition()等等，这些最终都在addStation()中被调用了，即你加入这个Sta节点的时候就被调用了，也没什么问题。
最后找到是在moveAssociationTo()中，即associateTo()中被调用。
这个很容易理解，因为手动设置关联的时候当然需要对条件进行判断，然后决定是否切换，即执行方法handover()。