-
Notifications
You must be signed in to change notification settings - Fork 674
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
Add support for IP_RECVERR #1514
Conversation
This failure is fun. What we've discovered is that something about (This might be a QEMU emulation bug for MIPS64 targets.)
|
Several QEMU targets are hitting bogus address families in the control message associated "error origin:" Linux arm gnueabi, Linux armv7 gnueabihf, Linux MIPS, Linux mipsel. Probably have to just disable QEMU tests as broken for now. |
Is it qemu-system or qemu-user? If it's the latter, I'm not particularly surprised. |
My guess is user, although I'm not sure how to tell from the cirrus config. So, I think both QEMU emulation bugs relate to Both problems appears to be bugs in
The
|
Oof, that's a complicated test. And the QEMU bug doesn't suprise me; there are plenty more where it came from. This PR LGTM. Just squash your commits and I'll merge it. |
Setting these options enables receiving errors, such as ICMP errors from the network, via `recvmsg()` with `MSG_ERRQUEUE`. Adds new `Ipv{4,6}RecvErr` variants to `ControlMessageOwned`. These control messages are produced when `Ipv4RecvErr` or `Ipv6RecvErr` options are enabled on a raw or datagram socket. New tests for the functionality can be run with `cargo test --test test test_recverr`. This commit builds on an earlier draft of the functionality authored by Matthew McPherrin <[email protected]>.
0255ea3
to
d23e7c7
Compare
Thanks! Squashed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
bors r+
This pull request adds support for setting the
IP_RECVERR
(and correspondingIPV6_RECVERR
) sockopt, and then decoding the resulting control messages fromrecvmsg()
. It is a Linux-specific API.This PR extends #1161 by:
IpvXRecvErr
control message optional (recvmsg
documentation claims it is not provided for some kinds of error), per @WGH-.I added some trivial doc comments on the
ControlMessageOwned
variants, but I'm not sure exactly what documentation you had in mind earlier on #1161.