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

socket: accepts function does not need the entire IpRepr #202

Closed
dlrobertson opened this issue May 8, 2018 · 4 comments
Closed

socket: accepts function does not need the entire IpRepr #202

dlrobertson opened this issue May 8, 2018 · 4 comments

Comments

@dlrobertson
Copy link
Collaborator

Each socket type (ICMP, UDP, and TCP) has a corresponding accetps function that determines if the given packet was meant for the current socket. Currently this function accepts the entire IpRepr, but only the source address and destination address are used.

@whitequark
Copy link
Contributor

Is this a problem? We already have the IpRepr.

@dlrobertson
Copy link
Collaborator Author

It isn't really a problem. I was primarily thinking of this as unused information. In particular I was thinking about the case where the packet is something like IPv6 > Hop-by-Hop > UDP. In this case the UDP socket accepts function will accept the IpRepr with a next_header value of Hop-by-Hop, but obviously repr would be a UdpRepr.

@whitequark
Copy link
Contributor

Yeah, that check is already done in EthernetInterface, so I didn't add it to accepts as redundant. We may add it for completeness, although it feels a bit pointless.

@Dirbaio
Copy link
Member

Dirbaio commented Dec 25, 2020

Hello! As part of issue cleanup I'm closing inactive or already-answered "question" issues, since they're not actionable.

Note this doesn't mean questions aren't welcome. They still are! It's just that they shouldn't stay open forever.

@Dirbaio Dirbaio closed this as completed Dec 25, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

3 participants