ObjFW  History of src/OFDDPSocket.m of f6cc2092af2a9dd2

This didn't work without problems on all OSes. Since ofatalkcfg is no
longer there, there is no reason to keep this for now. In the future, if
there is a more generic replacement for ofatalkcfg, this can just be
reverted. file: [0f90d0e13f] check-in: [550bd1b7bb] user: js, branch: trunk, size: 7539 [annotate] [blame] [check-ins using] [diff]

While Linux just ignores the protocol, NetBSD insists on it being 0.
Since this code path was also used by Windows, which requires it to be
ATPROTO_BASE + protocol, this means an extra code path for Windows is
needed now. file: [d532fdd70f] check-in: [4d97d89c32] user: js, branch: trunk, size: 7267 [annotate] [blame] [check-ins using] [diff]

This seems to be an oddity limited to OSes that have implemented DDP
exclusively for netatalk, while macOS and Windows don't include it with
the data.

While on macOS it's possible to achieve the previous behavior via some
hacks, this is impossible on Windows, so the proper approach is to
handle it like everybody else: Specify the protocol type when binding
and only handle packets of the correct protocol type. file: [11bd6fb256] check-in: [9c2f20e736] user: js, branch: trunk, size: 7082 [annotate] [blame] [check-ins using] [diff]

This required quite some reverse engineering, as it is all completely
undocumented.

Receiving worked pretty much as expected: Do a readv() and get the raw
DDP packet including headers, then parse the headers ourselves to get
the source and fill out an OFSocketAddress.

But sending was tricky and required reading through kernel sources.
writev() does not work on a raw DDP socket and always fails with
EDESTADDRREQ, even if the destination address is provided as part of the
raw DDP packet. Meanwhile, sendmsg() always creates a DDP packet for us,
even in raw mode, and prepends the data with what it believes to be the
DDP protocol type (the protocol parameter passed to socket()). After
reading through the kernel source for some time to find a way to disable
this behavior, I found that you can set DDP_HDRINCL in ATPROTO_NONE to
provide your entire header to sendmsg() instead to work around this,
making it behave like you would expect from a writev() to a raw socket.

The only missing part now is to return a proper address a socket was
bound to, as currently it just leaves network and node at 0 and only
fills the port. This probably just requires some more reading of kernel
sources. file: [0702a801d8] check-in: [41535b41da] user: js, branch: trunk, size: 5781 [annotate] [blame] [check-ins using] [diff]