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

fix: enter unreachable when discarding HBH Option with multicast destination address #996

Merged
merged 2 commits into from
Sep 27, 2024

Conversation

thvdveld
Copy link
Contributor

It was previously possible to enter an unreachable path when the HBH option type was 0b11 and the destination address was multicast. This is now fixed in the interface.

I also changed the way an HBH option type is parsed. Only the 2 highest order bits indicate what action must be taken, meaning that we can't have an unknown state.

It was previously possible to enter an unreachable path when the HBH
option type was 0b11 and the destination address was multicast. This is
now fixed in the interface.

I also changed the way an HBH option type is parsed. The option type is
only 2 bits, meaning that we can't have an unknown state.
Ipv6OptionFailureType::DiscardSendUnicast => {
if !ipv6_repr.dst_addr.is_multicast() {
return HopByHopResponse::Discard(param_problem());
}
Copy link
Member

Choose a reason for hiding this comment

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

we still have to return here if the sender is multicast, to discard the packet, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, indeed, I misread this in the RFC. I thought only the option needs to be discarded, but like you say, the full packet needs to be discarded, without sending an ICMP parameter problem back.

Discard the packet if the Hop-by-Hop header type is 0b11 and the packet
destination address is multicast.
@Dirbaio Dirbaio added this pull request to the merge queue Sep 27, 2024
Merged via the queue into smoltcp-rs:main with commit c114acd Sep 27, 2024
10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants