On Wed, Aug 24 2022, A Tammy <[email protected]> wrote:
> On 8/23/2022 11:33 PM, A Tammy wrote:
>> On 8/23/22 20:29, Jeremie Courreges-Anglas wrote:
>>> On Tue, Aug 23 2022, Jeremie Courreges-Anglas<[email protected]> wrote:
>>>> On Tue, Aug 23 2022, aisha<[email protected]> wrote:
>>>>> On 8/23/2022 7:20 AM, Jeremie Courreges-Anglas wrote:
>>>>>> On Mon, Aug 22 2022, aisha<[email protected]> wrote:
>>>>>>
>>> Well, before cleaning up this port I got curious and looked what
>>> happened if I specified --enable-quic. In that case an embedded copy of
>>> ngtcp2 is built, but the knot code fails to build with this error:
>>>
>>> utils/common/netio.c:343:34: error: use of undeclared identifier
>>> 'IP_RECVTOS'
>>> if (setsockopt(fd, IPPROTO_IP, IP_RECVTOS, &tos,
>>> sizeof(tos)) == -1) {
>>>
>>> We don't have IP_RECVTOS. It's useful to peek at the ECN bits on UDP
>>> sockets. Adding it to our kernel looked trivial but while adding it
>>> I fell into a rabbit hole trying to understand what happened with IP_TTL
>>> and IP_RECVTTL... (looks like we copied the FreeBSD code which passed
>>> userland IP_RECVTTL cmsgs to userland instead of IP_TTL).
> The knot developers response
>
>> Just to be sure, quic in knotd works on linux only (requires xdp).
> Kdig should work with quic.
> <https://matrix.to/#/!KyARDHjubBYDxQtezf:gitter.im/$LNTqUGntQE2dNyaIFiJ1C9xabBt1srhJILg9TKiw4jU?via=gitter.im&via=matrix.org&via=skyforge.at>
>> If it doesn't (we tested freebsd only), we will take a look at that.
> <https://matrix.to/#/!KyARDHjubBYDxQtezf:gitter.im/$uOFKcbieHiCEDSSC0IzURx8iklxZp-D077rI9zHVT58?via=gitter.im&via=matrix.org&via=skyforge.at>
>> Conventional quic in knotd should be available since 3.3.
I'm not on matrix/gitter etc so I'm not sure how to use those links,
however...
> This makes me think we should disable quic for now.
Well if XDP sockets are required that seems obvious for the server part.
For the client utilities parts, it could be enabled by either adding
support for IP_RECVTOS or patching out this code (the client utilities
won't get to look at ECN bits but I'm not sure it matters *that much*).
> In the meantime, they provided the following patch (its gonna be mangled
> by thunderbird but whatever) along with a statement "We have realized
> the patch isn't correct. But it somehow works"
>
>
> --- a/src/utils/common/netio.c
> +++ b/src/utils/common/netio.c
> @@ -340,7 +340,7 @@ static int fd_set_recv_ecn(int fd, int family)
> unsigned int tos = 1;
> switch (family) {
> case AF_INET:
> - if (setsockopt(fd, IPPROTO_IP, IP_RECVTOS, &tos,
> sizeof(tos)) == -1) {
> + if (setsockopt(fd, IPPROTO_IP, IP_TOS, &tos,
> sizeof(tos)) == -1) {
> return knot_map_errno();
> }
> break;
Indeed it seems dubious. At least on OpenBSD, it should set the TOS of
ougtoing packets to 1 (0x1)* and does not allow the caller to get the
TOS field of incoming packets using recvmsg(2). In ECN speak, 0x1 would
be CE, "Congestion Experienced", it doesn't make sense for a client to
send that unconditionally.
* test with nc -u -T 1 127.0.0.1 54:
1661368645.328378 127.0.0.1.18078 > 127.0.0.1.54: [udp sum ok] udp 5 [tos 0x1
(C)] (ttl 64, id 40148, len 33)
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
