You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Implement IP layer mode on macOS using socket(PF_INET, SOCK_RAW, IPPROTO_RAW) and setsockopt(IP_HDRINCL)
Teach recv-pcap to handle BSD loopback encapsulation as used by macOS utun interfaces
While here fix file descriptor leaks in bpf failure paths
Deliberately ifdef'ed macOS-specific code with __APPLE__ such that in the future, the code can be shared amongst macOS and BSDs lacking sendmmsg. If/when I get around to implement sendmmsg for BSD, I'll likely propose to split send code into bsd-legacy and bsd-sendmmsg, instead of send-bsd and send-mac with largely duplicate code for the "no sendmmsg available" case.
Deliberately ifdef'ed macOS-specific code with APPLE such that in the future, the code can be shared amongst macOS and BSDs lacking sendmmsg.
This makes sense, but I'm not sure if the code in that block is actually Apple-specific. It seems that the host-order part:
BSD loopback encapsulation; the link layer header is a 4-byte
field, in host byte order, containing a PF_ value from
socket.h for the network-layer protocol of the packet
The ifdef __APPLE__ is on the send path, the byte order comment there applies only to IP header fields when sending through a raw IP socket (as opposed to BPF device, used by zmap when -X is not given), and is independent of the link layer type of the interface. The packet sent to the socket begins with the IP header and has no link layer header. macOS requires the off and len fields of the IP header in host byte order when sending via raw IP sockets. FreeBSD used to require them in host byte order too, back when Apple forked the BSD portion of XNU from FreeBSD 4, but since FreeBSD 11, FreeBSD takes those fields in network byte order. When sending with those fields in host byte order on FreeBSD 14, or when sending with those fields in network byte order on macOS Sonoma, you get EINVAL from the sendto() calls. This can also be verified by comparing the «Raw IP Sockets» and «BUGS» sections of ip(4) for macOS and different versions of FreeBSD. We could cater for old FreeBSD too by checking for __FreeBSD_version < 1100030.
The BSD loopback encapsulation change on the other hand is on the libpcap receive path, and is only relevant to certain types of interfaces, including utun on macOS, which is used by at least some VPN software on macOS. I have not ifdef'ed that to __APPLE__, as it seems to compile fine on Linux etc too. The commit adding recv support for BSD loopback encapsulation is orthogonal to the rest of the changeset; sending in IP layer mode works without it. Zmap would not be able to receive packets over utun interfaces tho. Byte order of the protocol field in the BSD loopback encapsulation header is currently irrelevant, as zmap never interprets it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
socket(PF_INET, SOCK_RAW, IPPROTO_RAW)andsetsockopt(IP_HDRINCL)utuninterfacesDeliberately ifdef'ed macOS-specific code with
__APPLE__such that in the future, the code can be shared amongst macOS and BSDs lacking sendmmsg. If/when I get around to implement sendmmsg for BSD, I'll likely propose to split send code into bsd-legacy and bsd-sendmmsg, instead of send-bsd and send-mac with largely duplicate code for the "no sendmmsg available" case.