The PingingSelector in pan has probably been broken for a while. This hasn't been noticed, because, in the absence of meaningful measurements, it reverts to returning the first (i.e., shortest) path it knows.
I hit upon this problem by adding some code to inspect the state of pathStatsDB while the PingingSelector is in use. It's internal maps remain unpopulated no matter how long the PingingSelector is in use. I also tested this with the scion-ssh-client implementation to confirm the problem.
The PingingSelector uses somewhat low-level code to obtain the latency measurements in the backend. Perhaps something changed on the wire since then?
The PingingSelector in pan has probably been broken for a while. This hasn't been noticed, because, in the absence of meaningful measurements, it reverts to returning the first (i.e., shortest) path it knows.
I hit upon this problem by adding some code to inspect the state of pathStatsDB while the PingingSelector is in use. It's internal maps remain unpopulated no matter how long the PingingSelector is in use. I also tested this with the scion-ssh-client implementation to confirm the problem.
The PingingSelector uses somewhat low-level code to obtain the latency measurements in the backend. Perhaps something changed on the wire since then?