Beacon server getting looping PCBs

[kormat]

I expected that get_hops_hash would return the same hash for all PCBs for a given path in the test system. This doesn't appear to be the case however. For example, after ~10mins of uptime the ad 1-13 beacon servers have generated nearly 900 unique path segment revocation tokens:

 893 Generating new revocation token
3550 Using existing revocation token

@shitz

[kormat]

Ah. We're getting looping paths i think:

get_hops_hash: AD IDs: [22, 12, 11, 21, 22, 21, 22, 21, 11, 13] Digest: ddbf25facdc9020bdb08b1d57c6cab84d94d82b42015cb263172393b94495add

get_hops_hash: AD IDs: [13, 11, 21, 11, 21, 22, 21, 11, 13, 11, 13] Digest: 9dc11c223c3e003e8c8a4962c9050280717ece3a9419117c7ee2297865a477d6

[shitz]

This shouldn't happen, since PCBs get dropped if they have been received before (see beacon_server.py:636). I haven't followed the development of the BS too closely lately, but it seems that PCBs don't get dropped anymore (or only sometimes).

On Mon, Apr 27, 2015 at 5:47 PM, kormat notifications@github.com wrote:

Ah. We're getting looping paths i think:

get_hops_hash: AD IDs: [22, 12, 11, 21, 22, 21, 22, 21, 11, 13] Digest: ddbf25facdc9020bdb08b1d57c6cab84d94d82b42015cb263172393b94495add

— Reply to this email directly or view it on GitHub https://github.com/netsec-ethz/scion/issues/84#issuecomment-96718760.

[pszal]

For me it seems that process_pcbs() introduced that bug. It actually does not drop looping PCB (continue should be for outer for).

[kormat]

For me it seems that process_pcbs() introduced that bug. It actually does not drop looping PCB (continue should be for outer for).

That does indeed look suspicious. I think i broke that :) Lets see what happens if i fix it.

[kormat]

Yep. With that fixed:

  47 Generating new revocation token
 1248 Using existing revocation token