end2end_test.py fails in some cases about scion

[pszal]

Thanks, will investigate that

On 19.06.2015 12:26, Krishna Deepak wrote:

When |end2end_test.py| is run between 1,14(Intermediate node) and
1,18(Leaf node), it fails. It uses a PEER path for this case. The path
is 1,14 ---> 1,15 ---> 1,18. The first one is a PEER link while the
second one is a normal Parent-Child link.

I am attaching the output here:
https://gist.github.com/mskd96/0a7d44b092c2998a7a5c

AFAIK, the path information(IFID's) looks to be correct but the first
hop 127.1.14.83 corresponds to the edge router connected to 1,11 which
is the parent of 1,14. But, shouldn't it be the one corresponding to 1,15?
What might be the issue?

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

[mskd12]

@pszalach
I think the problem is with get_first_hop function in scion_elem.py. In this case, the first link is a PEER path, so the first opaque field to consider should be the peering one and not the one returned by get_first_hop_of. Maybe that case should be handled separately in this function like it is done while packet forwarding in router.py.
What do you think?

[pszal]

@mskd96 yes, I had few minutes yesterday to look at this.

1. as you found get_first_hop is wrong for this case, look at https://github.com/netsec-ethz/scion/compare/peer_link_fix
2. but even then router handles this case incorrectly (i.e, first router does not update of pointer correctly). However it works when sender (i.e. AD 1,14) puts increase_of(2) (i.e., set of's pointer to correct hop opaque field) before sending.

Unfortunately, I'll not be able to fix that next week, so if you have a fix before please describe it or create a PR.

[pszal]

#238