Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tutorial: topology source host missing causes scion-router@br.service to crash #4619

Merged
merged 3 commits into from
Sep 17, 2024

Conversation

thomasgruebl
Copy link
Contributor

Hi,

I've tried to setup the freestanding SCION network as per the tutorial and ran into a few issues:

Using the default topology files from the website, the scion-router service always crashes because of an invalid source IP (see screenshot below):

image

@tobiasmoldan realized that this can be resolved by adding the source IP (or host name) to the local field in the topology:

"underlay": { "local": "scion01:50012", "remote": "scion02:50012" },

Secondly, I was wondering if all ASes need to be up and running for the network to be fully functional? I have set up and configured scion01 and scion02 as per the tutorial. All services (daemon, router, control, dispatcher) are active and there is a direct link between the two VMs. The machines are pingable (via normal ICMP), however, there is no reachability via SCMP. I assume that, even without scion03-05, they should have connectivity?

I got scion addresses for scion01 and scion02 respectively,

42-ffaa:1:1,127.0.0.1

42-ffaa:1:2,127.0.0.1

and I have generated the certificate material on scion01 and shared it with scion02. Is there anything I'm missing - e.g., does path exploration need to be triggered somehow or should it happen automatically?

Thanks a lot for your help on this!

Best regards,

Thomas

@jiceatscion
Copy link
Contributor

This change is Reviewable

Copy link
Contributor

@jiceatscion jiceatscion left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

Reviewed 6 of 6 files at r1, all commit messages.
Reviewable status: :shipit: complete! all files reviewed, all discussions resolved (waiting on @thomasgruebl)

@jiceatscion
Copy link
Contributor

This is a it odd that two core ASes alone cannot talk. I see no reason for it. Does it start working as soon as you bring one or more of the others?

@jiceatscion jiceatscion changed the title Tutorial topology source host missing causes scion-router@br.service to crash tutorial: topology source host missing causes scion-router@br.service to crash Sep 17, 2024
@jiceatscion jiceatscion merged commit 24ec39d into scionproto:master Sep 17, 2024
5 checks passed
@thomasgruebl
Copy link
Contributor Author

Hi,

thanks for your response! Yes it's odd indeed. I have now configured scion03 as well (so all three core ASes are up and running). In Wireshark, I can even see path propagation packets being sent (and received) between all 3 ASes via UDP ports 50012, 50013, 50023, however, scion ping, showpaths and traceroute are still not working and outputting:

Error: fetching paths: no path available

I was wondering if you'd be available for a quick remote discussion sometime - then I could show you the setup?

Thanks,

Thomas

@thomasgruebl thomasgruebl deleted the tutorial-bugs branch September 18, 2024 20:09
@thomasgruebl
Copy link
Contributor Author

Hi @jiceatscion ,

I've now installed the SCION protocol dissector for Wireshark and I'm seeing the following messages being exchanged between the two ASes.

Screenshot 2024-09-21 at 13 14 23

This is a request from scion01 -> scion02:

Screenshot 2024-09-21 at 13 16 06

This is a response from scion02 -> scion01

Screenshot 2024-09-21 at 13 16 28

Can you infer something from the BFD control messages?

Thanks!

Thomas

@jiceatscion
Copy link
Contributor

Not sure if we can learn much from the BFD messages. Those don't call for a response; they're just mutual keep-alive packets. If they weren't there, then we would have a hint of why paths aren't available.

Recently we found that Go v1.23 was including a ~bug in timers behavior that was breaking the control service RPCs. If you're building the last release, you shouldn't be affected. But if you're building from head, then make sure you've pulled past the fix that downgrades Go to 1.22.7

@thomasgruebl
Copy link
Contributor Author

Hi @jiceatscion ,

Thanks for your reply! Unfortunately, that's not the case because I'm building the last release v0.11.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants