From owner-freebsd-hackers@freebsd.org Mon Nov 16 01:16:23 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 36CEF46EA46; Mon, 16 Nov 2020 01:16:23 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CZB3p1SDVz3vx9; Mon, 16 Nov 2020 01:16:21 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by mail-pf1-x42e.google.com with SMTP id 10so12206103pfp.5; Sun, 15 Nov 2020 17:16:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=UN5mwYYOvQhMlPDJBAGdGRMA71zPSShItFYE3dmsy7Y=; b=Fkngjd6lPSgRVV9rpkYNXnpBfOptwzpGOFBb9FAIErI/qzYLs4yRkdEw0+pS8iCGCA QxJ8yUiE/SQjz0qJd8XlvXnVmxpxjtlQ96+C088CzoOApWVi/KQhTaC3yvPSVSSf7XuK oI+smowIrI5aygJIDzbd0PLhnWqJgWYQBlPCXyHmczof9oG8O3A8wQJvZ2r+ThyTkRlD w7/Kp/6BxBxFKDlKlqn2Ix6V/qcW7X0HNRcwT2d1I6SDknQx0f/+0a47+nzM5Nw2P7fb 05Vw21qFAZ/3QN1QryryeqpOGJCKm4jUsXMbjdiSC/YruPUWWmikDB1HUv2O1GvXi3KG QLcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=UN5mwYYOvQhMlPDJBAGdGRMA71zPSShItFYE3dmsy7Y=; b=pJoBuBjvzTRyXf3NDQX8wiZo/t1HXGnRvqG+f2mdfbJ1JOd7E7ajGM9Pz3ohC4izTQ Gq0GuIyMoVbKwN01w5UiJd4I5ci9bpqpCtvNiO0xH8Vz/IIZp5bOftqDfkdt+dIeMDxr jK2VQniTGxH4YJaXhf6C0YSdHWpKb/SuicH7tQsvoMvUmsMHojQRr2rzaoAcSzmcjgYx R96cpGYnzutDAl8I2wCWvuyKQRETvH4xspqjtqUU1bWJZgzM9Y6vxMzOr/2U4/D6IO8n F180TOqU0TBbAl+G5glpG0Yofcl0yZEJDjRJZv0J8A013anqzyVfDuGSCfcybQQTHoz1 UNwQ== X-Gm-Message-State: AOAM531LEgRZhFpPeRb9EDHWMzyxFkTrdQ8pfwGDBfW3OWr7dpVssV/g hTLxLZ5NE63g7DxTc8Nv1sk= X-Google-Smtp-Source: ABdhPJzdE5+AEZhxHlvmBRVptniYkgWKxtoCi0fxxVmkAGGbmatxztAKHeRuY8KwkGE5+LRo/BuYCw== X-Received: by 2002:a17:90a:3cc4:: with SMTP id k4mr6662177pjd.106.1605489380127; Sun, 15 Nov 2020 17:16:20 -0800 (PST) Received: from localhost ([210.108.244.139]) by smtp.gmail.com with ESMTPSA id y5sm15583678pjr.50.2020.11.15.17.16.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 15 Nov 2020 17:16:18 -0800 (PST) Date: Mon, 16 Nov 2020 10:16:16 +0900 From: YongHyeon PYUN To: Lowell Gilbert Cc: freebsd-hackers@freebsd.org, freebsd-arm@freebsd.org Subject: Re: Problem with checksum offloading on RPi3 (PF + Jails involved) Message-ID: <20201116011616.GA1941@michelle> References: <748edc3d-4ef7-c4de-291f-7c0b460a6052@gmx.de> <5130ee46-5832-d4df-d774-c6bd32e10b30@gmx.de> <20201029213622.GM31099@funkthat.com> <55713894-A896-4F12-ABB9-93DFEB2F16B9@FreeBSD.org> <20201103045215.GA2524@michelle> <44zh3ybd0s.fsf@Be-Well.Ilk.Org> <20201104013017.GA48398@michelle> <44eel9bv5k.fsf@Be-Well.Ilk.Org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44eel9bv5k.fsf@Be-Well.Ilk.Org> X-Rspamd-Queue-Id: 4CZB3p1SDVz3vx9 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=Fkngjd6l; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of pyunyh@gmail.com designates 2607:f8b0:4864:20::42e as permitted sender) smtp.mailfrom=pyunyh@gmail.com X-Spamd-Result: default: False [-3.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[2607:f8b0:4864:20::42e:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[2607:f8b0:4864:20::42e:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::42e:from]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers,freebsd-arm] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 01:16:23 -0000 On Tue, Nov 03, 2020 at 11:31:03PM -0500, Lowell Gilbert wrote: > YongHyeon PYUN writes: > > > On Tue, Nov 03, 2020 at 11:50:27AM -0500, Lowell Gilbert wrote: [...] > > Sorry, but I only have the public data sheet currently. > http://ww1.microchip.com/downloads/en/devicedoc/ds_lan89530_60001347a.pdf > Oh, thanks a lot. > > FreeBSD's USB stack requires copy operation for received frames so > > driver does not need any padding in RX path and ethernet frame > > alignment in mbuf can be adjusted in the copy operation. Since > > FCS bytes have no use in upper stack at this moment, it would be > > even better to strip FCS if there is way to do that in H/W. > > As I read this, the FCS is stripped if the padding is, but if you do > that, you have to disable the IP RX checksum offloading. > That's the note at the bottom of page 71. > Yup, found it. > I think the padding after the status word is strictly to word-align the > frame start, so you seem to have what you're looking for. > > The pre-frame padding is set by a Hardware Configuration Register. > Yes it seems, I disabled it in my patch as it is not required. > > For TX checksum offloading support, we need more information on > > H/W's TX handling(TX_CTRL_0 and TX_CTRL_1) too. I guess it needs > > special magic sequence of programming(i.e. existence of > > SMSC_TX_CTRL_0_FIRST_SEG and SMSC_TX_CTRL_0_LAST_SEG) but it could > > be greatly simplified to program the H/W for TX checksum offloading > > since driver also have to copy entire mbuf chain to USB stack(i.e > > single big TX segment for the H/W). > > The scatter-gather handling is driven from the first and last segment > flags, but the checksum addition *seems* to just happen by magic if the > checksum enable flag is also set. According to this data sheet, the > checksum enable flag has no effect except on the first segment, but > setting it the same way in every segment would be prudent. > > I have no idea if all of the chips under this driver use the same > command word formats, but they probably do. > Linux driver seems to have no special handling on other revisions so I think you're right. The real issue in TX checksum offloading is workaround for H/W limitation(bug?). It looks like H/W does not correctly compute checksum when checksum insertion offset is in the last 4 bytes of the TX packet which would be the case for pure-TCP ACK segments. For UDP case, we probably can't enable checksum offloading since the H/W is not smart enough to change UDP checksum value to 0xffff. > My experience is several years ago, and I have no hardware to try things > out on... Me too. :-( From owner-freebsd-hackers@freebsd.org Mon Nov 16 01:19:15 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C07CC46EBFC; Mon, 16 Nov 2020 01:19:15 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CZB766d8Cz3wDQ; Mon, 16 Nov 2020 01:19:14 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by mail-pf1-x430.google.com with SMTP id v12so12186151pfm.13; Sun, 15 Nov 2020 17:19:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=WiEZNCemjnGzDHXIJU/a12aM+W1IXQEW2KOU1vAa0H0=; b=Sgrmaa9DpENwwpu/fIPxpzEzozT6bhBhD9UMLqUZKUdEYNJO5r3z9mO39VjbwXPgwS AIjqKUAdF/+T2Tk5HWsH1xyk3slbIptu9dzgo6p9I1+y51YAS48+UcxkGl9X+eFmYnzy OOz2eHwVr+XIPnixBhmbgAJp7I/CjOl33p3l/8Y3Y2u8qodrqEEYCwA/dqaqsNprcU+i fy5p2u0c9KHGTEqm4esGHljMmSnKfwXffxa7yvyld9u/jqT6BUeBDaeZ7FrcVLkFIsND FQuXpCknLwLmiewVUX7XGBxlcNkUwm3dzkzf6MndaWB6w32zR+kCvtRxtfOwNECvdMph GBAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=WiEZNCemjnGzDHXIJU/a12aM+W1IXQEW2KOU1vAa0H0=; b=CwUWZbUqznPjMkqQtYlyps/lI77TcAw86vsxdxz94CyN5sQU6Z8khdiDxSKrKbwv48 DhomICtvIeMwvsj7pAfsnRxKh9JHqZSBn0ndeOeEt0lenI1mY4c+5E0rY3hyHy1C6Uil 9zAUfca+GpyZOGJdPI7Hk+d/l28Dw7ipt/+TtpFTnTVJ2gQCBAcvuVszylXPNoAn3yPs xbfzaklmV3i+4BIF58XSEvUjK3SmNGQYcu3er7labE7bERhW+u5kpdQTYbgsomsE8tNd caf6z6y2hJMqMmQ8Nkpkjttz5Nxmleysw37i2CnfYogHEeMJLh0or58wJVbFqLgEoEMn Befg== X-Gm-Message-State: AOAM533CvAjN1Q49Low1gGNz31zbssoOFDSsDEflh+zBTTNPSW9VPmjl HFaxIK8qzIP8DFf9uHhs1CGT1NJXT9A= X-Google-Smtp-Source: ABdhPJxaP5JYGzQ40SFqDUFiDSglnIEmQSWXWRhKtOvhHbCWcvU9ONYZBN5aC5k6gsOq1ZzN+TUl7w== X-Received: by 2002:aa7:8281:0:b029:164:cc0f:2b3a with SMTP id s1-20020aa782810000b0290164cc0f2b3amr12218294pfm.30.1605489553631; Sun, 15 Nov 2020 17:19:13 -0800 (PST) Received: from localhost ([210.108.244.139]) by smtp.gmail.com with ESMTPSA id a11sm16417659pfn.125.2020.11.15.17.19.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 15 Nov 2020 17:19:12 -0800 (PST) Date: Mon, 16 Nov 2020 10:19:10 +0900 From: YongHyeon PYUN To: Carsten =?iso-8859-1?Q?B=E4cker?= Cc: Hans Petter Selasky , Kristof Provost , freebsd-arm@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Problem with checksum offloading on RPi3 (PF + Jails involved) Message-ID: <20201116011910.GB1941@michelle> References: <748edc3d-4ef7-c4de-291f-7c0b460a6052@gmx.de> <5130ee46-5832-d4df-d774-c6bd32e10b30@gmx.de> <20201029213622.GM31099@funkthat.com> <55713894-A896-4F12-ABB9-93DFEB2F16B9@FreeBSD.org> <20201103045215.GA2524@michelle> <46d08198-530c-cb4b-efa8-4edaf89471c1@selasky.org> <4dfaa9a3-c085-8466-a6e4-19f988b5ed3d@selasky.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="liOOAslEiF7prFVr" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 4CZB766d8Cz3wDQ X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=Sgrmaa9D; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of pyunyh@gmail.com designates 2607:f8b0:4864:20::430 as permitted sender) smtp.mailfrom=pyunyh@gmail.com X-Spamd-Result: default: False [-3.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; HAS_ATTACHMENT(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FREEMAIL_TO(0.00)[gmx.de]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[2607:f8b0:4864:20::430:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/mixed,text/plain,text/x-diff]; SPAMHAUS_ZRD(0.00)[2607:f8b0:4864:20::430:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::430:from]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm,freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 01:19:15 -0000 --liOOAslEiF7prFVr Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit On Wed, Nov 04, 2020 at 07:36:44AM +0100, Carsten Bäcker wrote: [...] > Hi, > > i applied the patch on -CURRENT but got a panic right after loading the > kernel. Most likely an unrelated problem. > > But i was able to apply the patch on releng/12.2 (with an offset). > Unfortunately it doesn't change the previously described behavior with > rxcsum and i didn't manage to get any reasonable debug-output. > > Since i can easily reproduce the problem. How else can i help? > Finally had time to read the LAN89530 data sheet. The data sheet still does not clear on several cases and it requires real H/W to experiment for various cases. I created a patch which adds more RX validation but it was not tested at all due to lack of H/W. Also I even don't know whether it works or not after this change. When it does not work it would be good to know debug out of smsc(4). --liOOAslEiF7prFVr Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="smsc.rx.patch" Index: sys/dev/usb/net/if_smsc.c =================================================================== --- sys/dev/usb/net/if_smsc.c (revision 367712) +++ sys/dev/usb/net/if_smsc.c (working copy) @@ -94,6 +94,8 @@ __FBSDID("$FreeBSD$"); #include #include +#include +#include #include "opt_platform.h" @@ -198,6 +200,9 @@ static void smsc_ifmedia_sts(struct ifnet *, struc static int smsc_chip_init(struct smsc_softc *sc); static int smsc_ioctl(struct ifnet *ifp, u_long cmd, caddr_t data); +static void smsc_rxfixup(struct ifnet *ifp, struct mbuf *m, int *pktlen); +static int smsc_rxeof(struct usb_ether *ue, struct usb_page_cache *pc, + unsigned int offset, struct ifnet *ifp, int pktlen); static const struct usb_config smsc_config[SMSC_N_TRANSFER] = { [SMSC_BULK_DT_WR] = { @@ -795,11 +800,8 @@ static int smsc_sethwcsum(struct smsc_softc *sc) return (err); } - /* Enable/disable the Rx checksum */ - if ((ifp->if_capabilities & ifp->if_capenable) & IFCAP_RXCSUM) - val |= SMSC_COE_CTRL_RX_EN; - else - val &= ~SMSC_COE_CTRL_RX_EN; + /* Always enable Rx checksum to simplify RX packet validation. */ + val |= SMSC_COE_CTRL_RX_EN; /* Enable/disable the Tx checksum (currently not supported) */ if ((ifp->if_capabilities & ifp->if_capenable) & IFCAP_TXCSUM) @@ -925,6 +927,119 @@ smsc_init(struct usb_ether *ue) smsc_start(ue); } +static void +smsc_rxfixup(struct ifnet *ifp, struct mbuf *m, int *pktlen) +{ + struct ether_header *eh; + struct ip *ip; + struct udphdr *uh; + int hlen, iplen, len; + uint16_t csum; + + len = *pktlen; + if (len < sizeof(struct ether_header) + sizeof(struct ip)) + return; + eh = mtod(m, struct ether_header *); + if (eh->ether_type != htons(ETHERTYPE_IP)) + return; + ip = (struct ip *)(eh + 1); + if (ip->ip_v != IPVERSION) + return; + + hlen = ip->ip_hl << 2; + len -= sizeof(struct ether_header); + if (hlen < sizeof(struct ip)) + return; + if (ntohs(ip->ip_len) < hlen) + return; + iplen = ntohs(ip->ip_len); + if (iplen != len) { + if (iplen < sizeof(struct ip) + 26) { + /* + * XXX + * It seems H/W does not provide a reliable way to + * know received ethernet frame length when sender + * adds padding bytes to meet minimum ethernet frame + * length. + * Find actual ethernet frame size by checking total IP + * datagram length. This does not work for VLAN tagged + * frames or non-IPv4 datagrams though. + */ + *pktlen -= (26 - iplen); + + /* + * The checksum appears to be simplistically calculated + * over the udp/tcp header and data up to the end of the + * eth frame. Which means if the eth frame is padded + * the csum calculation is incorrectly performed over + * the padding bytes as well. Therefore to be safe we + * ignore the H/W csum on frames less than or equal to + * 64 bytes. + */ + } + /* IP datagram length does not match packet length. */ + return; + } + if ((ifp->if_capenable & IFCAP_RXCSUM) == 0) + return; + + if (ip->ip_off & htons(IP_MF | IP_OFFMASK)) + return; /* can't handle fragmented packet. */ + + switch (ip->ip_p) { + case IPPROTO_TCP: + if (len < (hlen + sizeof(struct tcphdr))) + return; + break; + case IPPROTO_UDP: + if (len < (hlen + sizeof(struct udphdr))) + return; + uh = (struct udphdr *)((caddr_t)ip + hlen); + if (uh->uh_sum == 0) + return; /* no checksum. */ + break; + default: + return; + } + + if ((hlen - sizeof(struct ip)) > 0) { + /* XXX checksum fixup for IP options. */ + return; + } + /* Extract H/W computed checksum. */ + csum = be16dec(mtod(m, caddr_t) + *pktlen + ETHER_CRC_LEN); + m->m_pkthdr.csum_flags |= CSUM_DATA_VALID; + m->m_pkthdr.csum_data = csum; +} + +static int +smsc_rxeof(struct usb_ether *ue, struct usb_page_cache *pc, unsigned int offset, + struct ifnet *ifp, int pktlen) +{ + struct mbuf *m; + + m = m_getcl(M_NOWAIT, MT_DATA, M_PKTHDR); + if (m == NULL) { + if_inc_counter(ifp, IFCOUNTER_IQDROPS, 1); + return (ENOMEM); + } + m->m_len = m->m_pkthdr.len = MCLBYTES; + m_adj(m, ETHER_ALIGN); + + usbd_copy_out(pc, offset, mtod(m, caddr_t), pktlen); + + if_inc_counter(ifp, IFCOUNTER_IPACKETS, 1); + m->m_pkthdr.rcvif = ifp; + m->m_pkthdr.len = m->m_len = pktlen; + + pktlen -= (ETHER_CRC_LEN + SMSC_RX_CSUM_LEN); + smsc_rxfixup(ifp, m, &pktlen); + m->m_pkthdr.len = m->m_len = pktlen; + + (void)mbufq_enqueue(&ue->ue_rxq, m); + return (0); +} + /** * smsc_bulk_read_callback - Read callback used to process the USB URB * @xfer: the USB transfer @@ -942,7 +1057,6 @@ smsc_bulk_read_callback(struct usb_xfer *xfer, usb struct smsc_softc *sc = usbd_xfer_softc(xfer); struct usb_ether *ue = &sc->sc_ue; struct ifnet *ifp = uether_getifp(ue); - struct mbuf *m; struct usb_page_cache *pc; uint32_t rxhdr; int pktlen; @@ -956,7 +1070,7 @@ smsc_bulk_read_callback(struct usb_xfer *xfer, usb case USB_ST_TRANSFERRED: /* There is always a zero length frame after bringing the IF up */ - if (actlen < (sizeof(rxhdr) + ETHER_CRC_LEN)) + if (actlen < (sizeof(rxhdr) + ETHER_MIN_LEN + SMSC_RX_CSUM_LEN)) goto tr_setup; /* There maybe multiple packets in the USB frame, each will have a @@ -975,9 +1089,19 @@ smsc_bulk_read_callback(struct usb_xfer *xfer, usb goto tr_setup; usbd_copy_out(pc, off, &rxhdr, sizeof(rxhdr)); - off += (sizeof(rxhdr) + ETHER_ALIGN); + off += sizeof(rxhdr); rxhdr = le32toh(rxhdr); - + + /* + * XXX + * It seems H/W does not have a feature to limit maximum + * ethernet frame length allowed to receive path. The + * SMSC_RX_STAT_FRM_LENGTH macro can return up to 2^14 + * bytes. I think it's too dangerous to trust the H/W + * reported RX size without further information from + * vendor. Drop all RX ethernet frames bigger than + * (MCLBYTES - ETHER_ALIGN) bytes for safety. + */ pktlen = (uint16_t)SMSC_RX_STAT_FRM_LENGTH(rxhdr); smsc_dbg_printf(sc, "rx : rxhdr 0x%08x : pktlen %d : actlen %d : " @@ -989,88 +1113,19 @@ smsc_bulk_read_callback(struct usb_xfer *xfer, usb if_inc_counter(ifp, IFCOUNTER_IERRORS, 1); if (rxhdr & SMSC_RX_STAT_COLLISION) if_inc_counter(ifp, IFCOUNTER_COLLISIONS, 1); - } else { - /* Check if the ethernet frame is too big or too small */ - if ((pktlen < ETHER_HDR_LEN) || (pktlen > (actlen - off))) + if (pktlen > (MCLBYTES - ETHER_ALIGN)) { + /* Lost sync. */ goto tr_setup; - - /* Create a new mbuf to store the packet in */ - m = uether_newbuf(); - if (m == NULL) { - smsc_warn_printf(sc, "failed to create new mbuf\n"); - if_inc_counter(ifp, IFCOUNTER_IQDROPS, 1); - goto tr_setup; } - if (pktlen > m->m_len) { - smsc_dbg_printf(sc, "buffer too small %d vs %d bytes", - pktlen, m->m_len); - if_inc_counter(ifp, IFCOUNTER_IQDROPS, 1); - m_freem(m); + } else { + if (pktlen < (ETHER_MIN_LEN + SMSC_RX_CSUM_LEN) || + pktlen > (MCLBYTES - ETHER_ALIGN) || + pktlen > (actlen - off)) { + /* Lost sync. */ + if_inc_counter(ifp, IFCOUNTER_IERRORS, 1); goto tr_setup; } - usbd_copy_out(pc, off, mtod(m, uint8_t *), pktlen); - - /* Check if RX TCP/UDP checksumming is being offloaded */ - if ((ifp->if_capenable & IFCAP_RXCSUM) != 0) { - struct ether_header *eh; - - eh = mtod(m, struct ether_header *); - - /* Remove the extra 2 bytes of the csum */ - pktlen -= 2; - - /* The checksum appears to be simplistically calculated - * over the udp/tcp header and data up to the end of the - * eth frame. Which means if the eth frame is padded - * the csum calculation is incorrectly performed over - * the padding bytes as well. Therefore to be safe we - * ignore the H/W csum on frames less than or equal to - * 64 bytes. - * - * Ignore H/W csum for non-IPv4 packets. - */ - if ((be16toh(eh->ether_type) == ETHERTYPE_IP) && - (pktlen > ETHER_MIN_LEN)) { - struct ip *ip; - - ip = (struct ip *)(eh + 1); - if ((ip->ip_v == IPVERSION) && - ((ip->ip_p == IPPROTO_TCP) || - (ip->ip_p == IPPROTO_UDP))) { - /* Indicate the UDP/TCP csum has been calculated */ - m->m_pkthdr.csum_flags |= CSUM_DATA_VALID; - - /* Copy the TCP/UDP checksum from the last 2 bytes - * of the transfer and put in the csum_data field. - */ - usbd_copy_out(pc, (off + pktlen), - &m->m_pkthdr.csum_data, 2); - - /* The data is copied in network order, but the - * csum algorithm in the kernel expects it to be - * in host network order. - */ - m->m_pkthdr.csum_data = ntohs(m->m_pkthdr.csum_data); - - smsc_dbg_printf(sc, "RX checksum offloaded (0x%04x)\n", - m->m_pkthdr.csum_data); - } - } - - /* Need to adjust the offset as well or we'll be off - * by 2 because the csum is removed from the packet - * length. - */ - off += 2; - } - - /* Finally enqueue the mbuf on the receive queue */ - /* Remove 4 trailing bytes */ - if (pktlen < (4 + ETHER_HDR_LEN)) { - m_freem(m); - goto tr_setup; - } - uether_rxmbuf(ue, m, pktlen - 4); + smsc_rxeof(ue, pc, off, ifp, (int)pktlen); } /* Update the offset to move to the next potential packet */ @@ -1395,11 +1450,12 @@ smsc_chip_init(struct smsc_softc *sc) goto init_failed; } - /* Adjust the packet offset in the buffer (designed to try and align IP - * header on 4 byte boundary) + /* + * Set the RX packet offset in the buffer to 0(no padding) and + * discard errored ethernet frames. */ reg_val &= ~SMSC_HW_CFG_RXDOFF; - reg_val |= (ETHER_ALIGN << 9) & SMSC_HW_CFG_RXDOFF; + reg_val |= SMSC_HW_CFG_DRP; /* The following setings are used for 'turbo mode', a.k.a multiple frames * per Rx transaction (again info taken form Linux driver). @@ -1494,7 +1550,6 @@ smsc_ioctl(struct ifnet *ifp, u_long cmd, caddr_t struct ifreq *ifr; int rc; int mask; - int reinit; if (cmd == SIOCSIFCAP) { sc = uether_getsc(ue); @@ -1503,25 +1558,14 @@ smsc_ioctl(struct ifnet *ifp, u_long cmd, caddr_t SMSC_LOCK(sc); rc = 0; - reinit = 0; mask = ifr->ifr_reqcap ^ ifp->if_capenable; /* Modify the RX CSUM enable bits */ if ((mask & IFCAP_RXCSUM) != 0 && - (ifp->if_capabilities & IFCAP_RXCSUM) != 0) { + (ifp->if_capabilities & IFCAP_RXCSUM) != 0) ifp->if_capenable ^= IFCAP_RXCSUM; - - if (ifp->if_drv_flags & IFF_DRV_RUNNING) { - ifp->if_drv_flags &= ~IFF_DRV_RUNNING; - reinit = 1; - } - } - SMSC_UNLOCK(sc); - if (reinit) - uether_init(ue); - } else { rc = uether_ioctl(ifp, cmd, data); } Index: sys/dev/usb/net/if_smscreg.h =================================================================== --- sys/dev/usb/net/if_smscreg.h (revision 367712) +++ sys/dev/usb/net/if_smscreg.h (working copy) @@ -116,6 +116,8 @@ #define SMSC_RX_STAT_DRIBBLING (0x1UL << 2) #define SMSC_RX_STAT_CRC_ERROR (0x1UL << 1) +#define SMSC_RX_CSUM_LEN 2 + /** * REGISTERS * --liOOAslEiF7prFVr-- From owner-freebsd-hackers@freebsd.org Mon Nov 16 11:54:29 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DC1412EC8D3; Mon, 16 Nov 2020 11:54:29 +0000 (UTC) (envelope-from carbaecker@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CZSD54669z3HDN; Mon, 16 Nov 2020 11:54:29 +0000 (UTC) (envelope-from carbaecker@gmx.de) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1605527667; bh=Rq62OD5TYdrCo7VP6e4VSKzUU/SDHTIhVEi1BTngum4=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=fd0FUVfVNiSvOCc0mKGE7THsjXPzTuUJ2Djk5xkvzAoMZnMzjZAzNQBkXfqIn9Jo0 eMedWwBDL9ZqpbjbqhKn4T3oVslmw9UdWgQLBt1oQiJJwhfNUs+4FsMy2m9FtL597t ShdUV0tcXJyX3KQYQ8LkQsyG+2l88J3opFBt+Dt0= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.30] ([94.31.96.148]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MbRfv-1k82MV3TLN-00buUb; Mon, 16 Nov 2020 12:54:26 +0100 Subject: Re: Problem with checksum offloading on RPi3 (PF + Jails involved) To: YongHyeon PYUN Cc: Hans Petter Selasky , Kristof Provost , freebsd-arm@freebsd.org, freebsd-hackers@freebsd.org References: <748edc3d-4ef7-c4de-291f-7c0b460a6052@gmx.de> <5130ee46-5832-d4df-d774-c6bd32e10b30@gmx.de> <20201029213622.GM31099@funkthat.com> <55713894-A896-4F12-ABB9-93DFEB2F16B9@FreeBSD.org> <20201103045215.GA2524@michelle> <46d08198-530c-cb4b-efa8-4edaf89471c1@selasky.org> <4dfaa9a3-c085-8466-a6e4-19f988b5ed3d@selasky.org> <20201116011910.GB1941@michelle> From: =?UTF-8?Q?Carsten_B=c3=a4cker?= Message-ID: <1245cbe5-9d2f-4808-f989-569ae7d57a8a@gmx.de> Date: Mon, 16 Nov 2020 12:54:25 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: <20201116011910.GB1941@michelle> Content-Type: multipart/mixed; boundary="------------759182F27CF02C4EEA64D72D" Content-Language: de-DE X-Provags-ID: V03:K1:ftziIChQwT8TYbWtF1y53OJG69B9SzuM7MFKo0G4Gs17sZMmVY7 lqa6IBMXVLXLlZLO/K9Bn5Uj0U2hhhbmuwNvE0quOxMGxpeTPTqN057Hu7mBHV3DlVsI8xp AQCXKBIDhFqjpY2KXD1t01cg9fOHcmTXZdP3twwFmNNtquE+uB/qcH7WTIO4IKa7Y/gVvlA 77nX8ev2+DblBwC8czqZA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:dnk/iF8Zqjs=:7q1dVkoZRyZ8VOPZ1hIueG C9edPqZuWiDg6ULOR04rgKpPg1bGXFYxbvM349QolPb9IWJcn+b/FbQZv27GgbrIxIoCg69pr i6G43g2DR3EM6pGfk/1YyMap4oNisJ7Gf3D8uQODo5QR7szO1PP8zM08Sc9lVidrB1cOIKXdz XBcbSa1NmXJvBl8NuSwK3OTnkfvU54kFXCnRzCWmbamaYtbs3UmBc4jUrzDPIKfglSHAWUxbZ nim5mJJkUR2qkPJK/igIQ2xy/wpY1gtwA4bSJGTCRSvGU2dAvgDG+/ntjeIgDDv2YQwEakmzE W4xaOidCS3SKQg1INr0YSCya/MiIPgH2IqIhzOiNQSHN5PZ+pI6wBXQLOJKzcPY8WrgWIkDbK GRjFbrOceoWVJBeaO2v5vHbYPw/8MgVPIXMAVigPfhi+LPpzCXP1I5nQj68/5S260TbBHRG7k 4vKEc9wk3Ui2m9Q5qJBghrs+CUc80nvqPEuz9JNvTFehJ5BkNrS1dbDfqugUIF/n0UoBaibLF t142FkB67F/d12h9zvcoHxLRc+FX7mHJm6Mg1/69BK+mUIJW31hHRhDrnJVR+c8Z31Dk92s0f LkCvG5NUxEZmMpFoBN/bH1Df2ucxriTMdqtuiBRZbB3gQmntiHn9LzGfRv1hg0lCcA0oezDNG lfqnR+inrs4CdngVdNBqhHQfhRUK4nfrcumDMSRgxbUsjV5+ytam4IT52AkTOfx/azSsvaeBu QYRXbZWFz1sO+X/WceLQOolLoA+WpohnHo4ws42oDRz1b7wfM1hYBJmr2LXceA+WDhJW8+jrJ xxwQlZe/b1bwuheLUEAo1btZAD0yR8mhh/N8j3yqSiMLcz4t6Ms5b0nJ9SBQJqRa4irzebiH4 Wo8PASZp62Yi4OmPqS/A== X-Rspamd-Queue-Id: 4CZSD54669z3HDN X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 11:54:29 -0000 This is a multi-part message in MIME format. --------------759182F27CF02C4EEA64D72D Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Am 16.11.2020 um 02:19 schrieb YongHyeon PYUN: > On Wed, Nov 04, 2020 at 07:36:44AM +0100, Carsten B=E4cker wrote: > > [...] > >> Hi, >> >> i applied the patch on -CURRENT but got a panic right after loading the >> kernel. Most likely an unrelated problem. >> >> But i was able to apply the patch on releng/12.2 (with an offset). >> Unfortunately it doesn't change the previously described behavior with >> rxcsum and i didn't manage to get any reasonable debug-output. >> >> Since i can easily reproduce the problem. How else can i help? >> > Finally had time to read the LAN89530 data sheet. The data sheet > still does not clear on several cases and it requires real H/W to > experiment for various cases. I created a patch which adds more > RX validation but it was not tested at all due to lack of H/W. Also > I even don't know whether it works or not after this change. When > it does not work it would be good to know debug out of smsc(4). > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.or= g" Hi, i just did a test with your modification. The good news is that the driver itself still works. The bad news is that it doesn't solve the problem. :-( I used the snapshot from 2020-10-29 as i already had an sdcard with that image. http://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/13.0/ Kernel was build from head + your patch. FreeBSD generic 13.0-CURRENT FreeBSD 13.0-CURRENT #1 r367714M: Mon Nov 16 08:03:24 UTC 2020 root@sysbuild:/usr/obj/usr/src_head/arm64.aarch64/sys/GENERIC arm64 Log from smsc is attached. As the lack of hardware seems to be a problem... i may be able to provide temporary access, incl. serial using a 2nd pi - but this will take some time as i need to change the network-setup. Regards, Carsten --------------759182F27CF02C4EEA64D72D Content-Type: text/plain; charset=UTF-8; name="debug_smsc.log" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="debug_smsc.log" hw.usb.smsc.debug: 0 -> 16 smsc0: debug: rx : actlen 315 smsc0: debug: rx : rxhdr 0x01372420 : pktlen 311 : actlen 315 : off 4 smsc0: debug: rx : actlen 94 smsc0: debug: rx : rxhdr 0x005a0020 : pktlen 90 : actlen 94 : off 4 smsc0: debug: rx : actlen 70 smsc0: debug: rx : rxhdr 0x00422420 : pktlen 66 : actlen 70 : off 4 smsc0: debug: rx : actlen 70 smsc0: debug: rx : rxhdr 0x00422420 : pktlen 66 : actlen 70 : off 4 smsc0: debug: rx : actlen 315 smsc0: debug: rx : rxhdr 0x01372420 : pktlen 311 : actlen 315 : off 4 smsc0: debug: rx : actlen 315 smsc0: debug: rx : rxhdr 0x01372420 : pktlen 311 : actlen 315 : off 4 smsc0: debug: rx : actlen 70 smsc0: debug: rx : rxhdr 0x00422420 : pktlen 66 : actlen 70 : off 4 smsc0: debug: rx : actlen 70 smsc0: debug: rx : rxhdr 0x00422420 : pktlen 66 : actlen 70 : off 4 smsc0: debug: rx : actlen 315 smsc0: debug: rx : rxhdr 0x01372420 : pktlen 311 : actlen 315 : off 4 smsc0: debug: rx : actlen 70 smsc0: debug: rx : rxhdr 0x00422420 : pktlen 66 : actlen 70 : off 4 smsc0: debug: rx : actlen 315 smsc0: debug: rx : rxhdr 0x01372420 : pktlen 311 : actlen 315 : off 4 smsc0: debug: rx : actlen 70 smsc0: debug: rx : rxhdr 0x00422420 : pktlen 66 : actlen 70 : off 4 smsc0: debug: rx : actlen 70 smsc0: debug: rx : rxhdr 0x00422420 : pktlen 66 : actlen 70 : off 4 smsc0: debug: rx : actlen 70 smsc0: debug: rx : rxhdr 0x00422420 : pktlen 66 : actlen 70 : off 4 smsc0: debug: rx : actlen 70 smsc0: debug: rx : rxhdr 0x00422420 : pktlen 66 : actlen 70 : off 4 smsc0: debug: rx : actlen 315 smsc0: debug: rx : rxhdr 0x01372420 : pktlen 311 : actlen 315 : off 4 smsc0: debug: rx : actlen 70 smsc0: debug: rx : rxhdr 0x00422420 : pktlen 66 : actlen 70 : off 4 smsc0: debug: rx : actlen 70 smsc0: debug: rx : rxhdr 0x00422420 : pktlen 66 : actlen 70 : off 4 smsc0: debug: rx : actlen 70 smsc0: debug: rx : rxhdr 0x00420020 : pktlen 66 : actlen 70 : off 4 smsc0: debug: rx : actlen 94 smsc0: debug: rx : rxhdr 0x005a0020 : pktlen 90 : actlen 94 : off 4 smsc0: debug: rx : actlen 315 smsc0: debug: rx : rxhdr 0x01372420 : pktlen 311 : actlen 315 : off 4 smsc0: debug: rx : actlen 70 smsc0: debug: rx : rxhdr 0x00422420 : pktlen 66 : actlen 70 : off 4 smsc0: debug: rx : actlen 102 smsc0: debug: rx : rxhdr 0x00622420 : pktlen 98 : actlen 102 : off 4 smsc0: debug: rx : actlen 70 smsc0: debug: rx : rxhdr 0x00422420 : pktlen 66 : actlen 70 : off 4 smsc0: debug: rx : actlen 70 smsc0: debug: rx : rxhdr 0x00422420 : pktlen 66 : actlen 70 : off 4 smsc0: debug: rx : actlen 315 smsc0: debug: rx : rxhdr 0x01372420 : pktlen 311 : actlen 315 : off 4 smsc0: debug: rx : actlen 102 smsc0: debug: rx : rxhdr 0x00622420 : pktlen 98 : actlen 102 : off 4 smsc0: debug: rx : actlen 102 smsc0: debug: rx : rxhdr 0x00622420 : pktlen 98 : actlen 102 : off 4 smsc0: debug: rx : actlen 315 smsc0: debug: rx : rxhdr 0x01372420 : pktlen 311 : actlen 315 : off 4 smsc0: debug: rx : actlen 70 smsc0: debug: rx : rxhdr 0x00422420 : pktlen 66 : actlen 70 : off 4 smsc0: debug: rx : actlen 70 smsc0: debug: rx : rxhdr 0x00422420 : pktlen 66 : actlen 70 : off 4 smsc0: debug: rx : actlen 315 smsc0: debug: rx : rxhdr 0x01372420 : pktlen 311 : actlen 315 : off 4 smsc0: debug: rx : actlen 315 smsc0: debug: rx : rxhdr 0x01372420 : pktlen 311 : actlen 315 : off 4 smsc0: debug: rx : actlen 70 smsc0: debug: rx : rxhdr 0x00422420 : pktlen 66 : actlen 70 : off 4 smsc0: debug: rx : actlen 70 smsc0: debug: rx : rxhdr 0x00422420 : pktlen 66 : actlen 70 : off 4 smsc0: debug: rx : actlen 315 smsc0: debug: rx : rxhdr 0x01372420 : pktlen 311 : actlen 315 : off 4 smsc0: debug: rx : actlen 315 smsc0: debug: rx : rxhdr 0x01372420 : pktlen 311 : actlen 315 : off 4 smsc0: debug: rx : actlen 70 smsc0: debug: rx : rxhdr 0x00422420 : pktlen 66 : actlen 70 : off 4 smsc0: debug: rx : actlen 70 smsc0: debug: rx : rxhdr 0x00422420 : pktlen 66 : actlen 70 : off 4 smsc0: debug: rx : actlen 315 smsc0: debug: rx : rxhdr 0x01372420 : pktlen 311 : actlen 315 : off 4 smsc0: debug: rx : actlen 3048 smsc0: debug: rx : rxhdr 0x05f00020 : pktlen 1520 : actlen 3048 : off 4 smsc0: debug: rx : rxhdr 0x05f00020 : pktlen 1520 : actlen 3048 : off 1528 smsc0: debug: rx : actlen 4572 smsc0: debug: rx : rxhdr 0x05f00020 : pktlen 1520 : actlen 4572 : off 4 smsc0: debug: rx : rxhdr 0x05f00020 : pktlen 1520 : actlen 4572 : off 1528 smsc0: debug: rx : rxhdr 0x05f00020 : pktlen 1520 : actlen 4572 : off 3052 smsc0: debug: rx : actlen 7620 smsc0: debug: rx : rxhdr 0x05f00020 : pktlen 1520 : actlen 7620 : off 4 smsc0: debug: rx : rxhdr 0x05f00020 : pktlen 1520 : actlen 7620 : off 1528 smsc0: debug: rx : rxhdr 0x05f00020 : pktlen 1520 : actlen 7620 : off 3052 smsc0: debug: rx : rxhdr 0x05f00020 : pktlen 1520 : actlen 7620 : off 4576 smsc0: debug: rx : rxhdr 0x05f00020 : pktlen 1520 : actlen 7620 : off 6100 smsc0: debug: rx : actlen 6096 smsc0: debug: rx : rxhdr 0x05f00020 : pktlen 1520 : actlen 6096 : off 4 smsc0: debug: rx : rxhdr 0x05f00020 : pktlen 1520 : actlen 6096 : off 1528 smsc0: debug: rx : rxhdr 0x05f00020 : pktlen 1520 : actlen 6096 : off 3052 smsc0: debug: rx : rxhdr 0x05f00020 : pktlen 1520 : actlen 6096 : off 4576 smsc0: debug: rx : actlen 4572 smsc0: debug: rx : rxhdr 0x05f00020 : pktlen 1520 : actlen 4572 : off 4 smsc0: debug: rx : rxhdr 0x05f00020 : pktlen 1520 : actlen 4572 : off 1528 smsc0: debug: rx : rxhdr 0x05f00020 : pktlen 1520 : actlen 4572 : off 3052 smsc0: debug: rx : actlen 4572 smsc0: debug: rx : rxhdr 0x05f00020 : pktlen 1520 : actlen 4572 : off 4 smsc0: debug: rx : rxhdr 0x05f00020 : pktlen 1520 : actlen 4572 : off 1528 smsc0: debug: rx : rxhdr 0x05f00020 : pktlen 1520 : actlen 4572 : off 3052 smsc0: debug: rx : actlen 4168 smsc0: debug: rx : rxhdr 0x05f00020 : pktlen 1520 : actlen 4168 : off 4 smsc0: debug: rx : rxhdr 0x05f00020 : pktlen 1520 : actlen 4168 : off 1528 smsc0: debug: rx : rxhdr 0x045c0020 : pktlen 1116 : actlen 4168 : off 3052 smsc0: debug: rx : actlen 1524 smsc0: debug: rx : rxhdr 0x05f00020 : pktlen 1520 : actlen 1524 : off 4 smsc0: debug: rx : actlen 10668 smsc0: debug: rx : rxhdr 0x05f00020 : pktlen 1520 : actlen 10668 : off 4 smsc0: debug: rx : rxhdr 0x05f00020 : pktlen 1520 : actlen 10668 : off 1528 smsc0: debug: rx : rxhdr 0x05f00020 : pktlen 1520 : actlen 10668 : off 3052 smsc0: debug: rx : rxhdr 0x05f00020 : pktlen 1520 : actlen 10668 : off 4576 smsc0: debug: rx : rxhdr 0x05f00020 : pktlen 1520 : actlen 10668 : off 6100 smsc0: debug: rx : rxhdr 0x05f00020 : pktlen 1520 : actlen 10668 : off 7624 smsc0: debug: rx : rxhdr 0x05f00020 : pktlen 1520 : actlen 10668 : off 9148 smsc0: debug: rx : actlen 9144 smsc0: debug: rx : rxhdr 0x05f00020 : pktlen 1520 : actlen 9144 : off 4 smsc0: debug: rx : rxhdr 0x05f00020 : pktlen 1520 : actlen 9144 : off 1528 smsc0: debug: rx : rxhdr 0x05f00020 : pktlen 1520 : actlen 9144 : off 3052 smsc0: debug: rx : rxhdr 0x05f00020 : pktlen 1520 : actlen 9144 : off 4576 smsc0: debug: rx : rxhdr 0x05f00020 : pktlen 1520 : actlen 9144 : off 6100 smsc0: debug: rx : rxhdr 0x05f00020 : pktlen 1520 : actlen 9144 : off 7624 smsc0: debug: rx : actlen 10668 smsc0: debug: rx : rxhdr 0x05f00020 : pktlen 1520 : actlen 10668 : off 4 smsc0: debug: rx : rxhdr 0x05f00020 : pktlen 1520 : actlen 10668 : off 1528 smsc0: debug: rx : rxhdr 0x05f00020 : pktlen 1520 : actlen 10668 : off 3052 smsc0: debug: rx : rxhdr 0x05f00020 : pktlen 1520 : actlen 10668 : off 4576 smsc0: debug: rx : rxhdr 0x05f00020 : pktlen 1520 : actlen 10668 : off 6100 smsc0: debug: rx : rxhdr 0x05f00020 : pktlen 1520 : actlen 10668 : off 7624 smsc0: debug: rx : rxhdr 0x05f00020 : pktlen 1520 : actlen 10668 : off 9148 smsc0: debug: rx : actlen 2644 smsc0: debug: rx : rxhdr 0x05f00020 : pktlen 1520 : actlen 2644 : off 4 smsc0: debug: rx : rxhdr 0x045c0020 : pktlen 1116 : actlen 2644 : off 1528 smsc0: debug: rx : actlen 315 smsc0: debug: rx : rxhdr 0x01372420 : pktlen 311 : actlen 315 : off 4 smsc0: debug: rx : actlen 70 smsc0: debug: rx : rxhdr 0x00422420 : pktlen 66 : actlen 70 : off 4 smsc0: debug: rx : actlen 70 smsc0: debug: rx : rxhdr 0x00422420 : pktlen 66 : actlen 70 : off 4 smsc0: debug: rx : actlen 315 smsc0: debug: rx : rxhdr 0x01372420 : pktlen 311 : actlen 315 : off 4 smsc0: debug: rx : actlen 315 smsc0: debug: rx : rxhdr 0x01372420 : pktlen 311 : actlen 315 : off 4 hw.usb.smsc.debug: 16 -> 0 --------------759182F27CF02C4EEA64D72D-- From owner-freebsd-hackers@freebsd.org Mon Nov 16 13:07:37 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id ECD322EF201 for ; Mon, 16 Nov 2020 13:07:37 +0000 (UTC) (envelope-from pjfloyd@wanadoo.fr) Received: from smtp.smtpout.orange.fr (smtp13.smtpout.orange.fr [80.12.242.135]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Bizanga Labs SMTP Client Certificate", Issuer "Bizanga Labs CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CZTrS5drKz3MfB for ; Mon, 16 Nov 2020 13:07:35 +0000 (UTC) (envelope-from pjfloyd@wanadoo.fr) Received: from [192.168.1.17] ([2.7.192.66]) by mwinf5d75 with ME id t17Y2300N1SQe2i0317ZjZ; Mon, 16 Nov 2020 14:07:33 +0100 X-ME-Helo: [192.168.1.17] X-ME-Auth: cGpmbG95ZEB3YW5hZG9vLmZy X-ME-Date: Mon, 16 Nov 2020 14:07:33 +0100 X-ME-IP: 2.7.192.66 To: FreeBSD Hackers From: Paul Floyd Subject: FreeBSD 12.2 extra RW program header Message-ID: <8ff8067a-3354-3587-4eda-1aa802f6c86b@wanadoo.fr> Date: Mon, 16 Nov 2020 14:07:32 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: 4CZTrS5drKz3MfB X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of pjfloyd@wanadoo.fr has no SPF policy when checking 80.12.242.135) smtp.mailfrom=pjfloyd@wanadoo.fr X-Spamd-Result: default: False [-0.33 / 15.00]; FREEMAIL_FROM(0.00)[wanadoo.fr]; TO_DN_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[2.7.192.66:received]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[wanadoo.fr]; ASN(0.00)[asn:3215, ipnet:80.12.240.0/20, country:FR]; MID_RHS_MATCH_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[80.12.242.135:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[wanadoo.fr]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[80.12.242.135:from:127.0.2.255]; NEURAL_SPAM_SHORT(0.77)[0.770]; RCVD_IN_DNSWL_NONE(0.00)[80.12.242.135:from]; R_SPF_NA(0.00)[no SPF record]; RWL_MAILSPIKE_POSSIBLE(0.00)[80.12.242.135:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 13:07:38 -0000 Hi I see that FreeBSD 12.2 has added an extra RW program header. Can anyone explain what this does? (My initial guess is things like thread mutexes and barriers). Full details: 12.1 Program Headers:   Type           Offset             VirtAddr           PhysAddr                  FileSiz            MemSiz              Flg Align   PHDR           0x0000000000000040 0x0000000000200040 0x0000000000200040                  0x0000000000000230 0x0000000000000230  R      0x8   INTERP         0x0000000000000270 0x0000000000200270 0x0000000000200270                  0x0000000000000015 0x0000000000000015  R      0x1       [Requesting program interpreter: /libexec/ld-elf.so.1]   LOAD           0x0000000000000000 0x0000000000200000 0x0000000000200000                  0x000000000000086c 0x000000000000086c  R 0x1000   LOAD           0x0000000000001000 0x0000000000201000 0x0000000000201000                  0x00000000000006b0 0x00000000000006b0  R E 0x1000   LOAD           0x0000000000002000 0x0000000000202000 0x0000000000202000                  0x0000000000001158 0x0000000000002014  RW 0x1000   DYNAMIC        0x0000000000003028 0x0000000000203028 0x0000000000203028                  0x0000000000000130 0x0000000000000130  RW     0x8 12.2: Program Headers:   Type           Offset             VirtAddr           PhysAddr                  FileSiz            MemSiz              Flg Align   PHDR           0x0000000000000040 0x0000000000200040 0x0000000000200040                  0x0000000000000268 0x0000000000000268  R      0x8   INTERP         0x00000000000002a8 0x00000000002002a8 0x00000000002002a8                  0x0000000000000015 0x0000000000000015  R      0x1       [Requesting program interpreter: /libexec/ld-elf.so.1]   LOAD           0x0000000000000000 0x0000000000200000 0x0000000000200000                  0x00000000000008bc 0x00000000000008bc  R 0x1000   LOAD           0x00000000000008c0 0x00000000002018c0 0x00000000002018c0                  0x00000000000006c0 0x00000000000006c0  R E 0x1000   LOAD           0x0000000000000f80 0x0000000000202f80 0x0000000000202f80                  0x0000000000000158 0x0000000000000158  RW 0x1000 extra header here ->   LOAD           0x00000000000010d8 0x00000000002040d8 0x00000000002040d8                  0x0000000000000090 0x00000000000000a8  RW 0x1000   DYNAMIC        0x0000000000000fa8 0x0000000000202fa8 0x0000000000202fa8                  0x0000000000000130 0x0000000000000130  RW     0x8 A+ Paul From owner-freebsd-hackers@freebsd.org Mon Nov 16 13:27:43 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 034892EF791 for ; Mon, 16 Nov 2020 13:27:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4CZVHc1q1Nz3NZM for ; Mon, 16 Nov 2020 13:27:40 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 0AGDRVne076532 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 16 Nov 2020 15:27:34 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 0AGDRVne076532 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 0AGDRVqT076531; Mon, 16 Nov 2020 15:27:31 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 16 Nov 2020 15:27:31 +0200 From: Konstantin Belousov To: Paul Floyd Cc: FreeBSD Hackers Subject: Re: FreeBSD 12.2 extra RW program header Message-ID: References: <8ff8067a-3354-3587-4eda-1aa802f6c86b@wanadoo.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8ff8067a-3354-3587-4eda-1aa802f6c86b@wanadoo.fr> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 4CZVHc1q1Nz3NZM X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [-1.00 / 15.00]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2001:470:d5e7:1::1:from]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_SPF_SOFTFAIL(0.00)[~all:c]; NEURAL_SPAM_SHORT(1.00)[0.998]; SPAMHAUS_ZRD(0.00)[2001:470:d5e7:1::1:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_TO(0.00)[wanadoo.fr]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-hackers]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 13:27:43 -0000 On Mon, Nov 16, 2020 at 02:07:32PM +0100, Paul Floyd wrote: > Hi > > > I see that FreeBSD 12.2 has added an extra RW program header. > > Can anyone explain what this does? (My initial guess is things like thread > mutexes and barriers). > > Full details: That's not full details, you stripped readelf output that describes it. The first rw data segment is really ro after linking is finished, you can see that RELRO segment location is identical to the first loadable rw segment. It contains the following sections typically .ctors .dtors .dynamic .got .got (but not .got.plt) is patched by rtld during load. I do not remember when did we enabled relro. Most likely long time before 12.1, and the new segment is due to the way relro handling changed in lld 10. > > > 12.1 > > Program Headers: >   Type           Offset             VirtAddr           PhysAddr >                  FileSiz            MemSiz              Flg Align >   PHDR           0x0000000000000040 0x0000000000200040 0x0000000000200040 >                  0x0000000000000230 0x0000000000000230  R      0x8 >   INTERP         0x0000000000000270 0x0000000000200270 0x0000000000200270 >                  0x0000000000000015 0x0000000000000015  R      0x1 >       [Requesting program interpreter: /libexec/ld-elf.so.1] >   LOAD           0x0000000000000000 0x0000000000200000 0x0000000000200000 >                  0x000000000000086c 0x000000000000086c  R 0x1000 >   LOAD           0x0000000000001000 0x0000000000201000 0x0000000000201000 >                  0x00000000000006b0 0x00000000000006b0  R E 0x1000 >   LOAD           0x0000000000002000 0x0000000000202000 0x0000000000202000 >                  0x0000000000001158 0x0000000000002014  RW 0x1000 >   DYNAMIC        0x0000000000003028 0x0000000000203028 0x0000000000203028 >                  0x0000000000000130 0x0000000000000130  RW     0x8 > > 12.2: > > Program Headers: >   Type           Offset             VirtAddr           PhysAddr >                  FileSiz            MemSiz              Flg Align >   PHDR           0x0000000000000040 0x0000000000200040 0x0000000000200040 >                  0x0000000000000268 0x0000000000000268  R      0x8 >   INTERP         0x00000000000002a8 0x00000000002002a8 0x00000000002002a8 >                  0x0000000000000015 0x0000000000000015  R      0x1 >       [Requesting program interpreter: /libexec/ld-elf.so.1] >   LOAD           0x0000000000000000 0x0000000000200000 0x0000000000200000 >                  0x00000000000008bc 0x00000000000008bc  R 0x1000 >   LOAD           0x00000000000008c0 0x00000000002018c0 0x00000000002018c0 >                  0x00000000000006c0 0x00000000000006c0  R E 0x1000 >   LOAD           0x0000000000000f80 0x0000000000202f80 0x0000000000202f80 >                  0x0000000000000158 0x0000000000000158  RW 0x1000 > > > extra header here -> > >   LOAD           0x00000000000010d8 0x00000000002040d8 0x00000000002040d8 >                  0x0000000000000090 0x00000000000000a8  RW 0x1000 > >   DYNAMIC        0x0000000000000fa8 0x0000000000202fa8 0x0000000000202fa8 >                  0x0000000000000130 0x0000000000000130  RW     0x8 > > > A+ > > Paul > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Mon Nov 16 14:50:38 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id ABB0E4689CF for ; Mon, 16 Nov 2020 14:50:38 +0000 (UTC) (envelope-from pjfloyd@wanadoo.fr) Received: from smtp.smtpout.orange.fr (smtp13.smtpout.orange.fr [80.12.242.135]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Bizanga Labs SMTP Client Certificate", Issuer "Bizanga Labs CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CZX7K6jgnz3hck for ; Mon, 16 Nov 2020 14:50:37 +0000 (UTC) (envelope-from pjfloyd@wanadoo.fr) Received: from [192.168.1.17] ([2.7.192.66]) by mwinf5d75 with ME id t2qa2300g1SQe2i032qb4p; Mon, 16 Nov 2020 15:50:35 +0100 X-ME-Helo: [192.168.1.17] X-ME-Auth: cGpmbG95ZEB3YW5hZG9vLmZy X-ME-Date: Mon, 16 Nov 2020 15:50:35 +0100 X-ME-IP: 2.7.192.66 Subject: Re: FreeBSD 12.2 extra RW program header To: FreeBSD Hackers References: <8ff8067a-3354-3587-4eda-1aa802f6c86b@wanadoo.fr> From: Paul Floyd Message-ID: <3520fd5a-9b8f-6766-ce6b-4014dc3b4776@wanadoo.fr> Date: Mon, 16 Nov 2020 15:50:33 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: 4CZX7K6jgnz3hck X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of pjfloyd@wanadoo.fr has no SPF policy when checking 80.12.242.135) smtp.mailfrom=pjfloyd@wanadoo.fr X-Spamd-Result: default: False [-1.96 / 15.00]; FREEMAIL_FROM(0.00)[wanadoo.fr]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.86)[-0.865]; RECEIVED_SPAMHAUS_PBL(0.00)[2.7.192.66:received]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[wanadoo.fr]; ASN(0.00)[asn:3215, ipnet:80.12.240.0/20, country:FR]; MID_RHS_MATCH_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[80.12.242.135:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[wanadoo.fr]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[80.12.242.135:from:127.0.2.255]; RCVD_IN_DNSWL_NONE(0.00)[80.12.242.135:from]; R_SPF_NA(0.00)[no SPF record]; RWL_MAILSPIKE_POSSIBLE(0.00)[80.12.242.135:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 14:50:38 -0000 On 11/16/20 2:27 PM, Konstantin Belousov wrote: > That's not full details, you stripped readelf output that describes it. > > The first rw data segment is really ro after linking is finished, you can > see that RELRO segment location is identical to the first loadable rw segment. > It contains the following sections typically > .ctors .dtors .dynamic .got > .got (but not .got.plt) is patched by rtld during load. > > I do not remember when did we enabled relro. Most likely long time before 12.1, > and the new segment is due to the way relro handling changed in lld 10. Hi Looking a bit more at the rest of the readelf output I see that there is one RW segement, as you say with .ctors .dtors etc. The added one just seems to have __progname. There are also significant debuginfo changes. Time to go and scratch my head a bit. A+ Paul From owner-freebsd-hackers@freebsd.org Tue Nov 17 03:04:11 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 54FB747D343; Tue, 17 Nov 2020 03:04:11 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CZrPl0SzKz3Hq4; Tue, 17 Nov 2020 03:04:10 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by mail-pg1-x530.google.com with SMTP id p68so4589134pga.6; Mon, 16 Nov 2020 19:04:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=YM2ARcgAMzohXhaLuHy5v5RBlHGah6MdJotnzYDAuCk=; b=KoSGMQgTE1JSY0bqmrrYmgFZe4O1iWKeDU2RWBywYH3mlJDJ0jDKMLMO2aYYn6HC/w AaKqNmWtR0NA5+LsjJmDxuXrG44OyEk/fnW0WPGirnAIudaKWLlaBIPG1ZMBR5S25QJE uZOFZAR9jfnHm34157NypZxcCs7YsEk/iiLHJyzdZU/oylIGpfLZXzGf1w/Gj0OiU3Nq 041mYODB23XLRLcetXTTHgO14s6ieSalbxCdyVrGmLsQAmrZMVjbGA7Ntb4TcXOrHVcY Jb/dm8ytakvz/8Ju8e3jxCNWPk/HNdPNJm2BAkW+e1RbYbKPmTn1C368Pp7yCqVmiE8X Qe4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=YM2ARcgAMzohXhaLuHy5v5RBlHGah6MdJotnzYDAuCk=; b=JzOxhf6nuf4q5e6lRUBJBM+hMPPcNPxhvNhI/ePzPbkve8ro/2GO2zcZ9TQNzb4zT1 8i+mcTKz0Lz38dU35NK+vYph85ZFVXAClPgoArF6EOvfSdgtlEjDc5dX6yxwWyEpDka3 QpW+5a8SVsSF3AKZaYxYzzBPV0NrhgLCzAqa988bJiudiNuLLDBihlRxT9/dOtsv8nZ6 ReLcUtu6irtfIiZsG/kK+IKsWnCEHDvUZIotU9tmETQ/wjSm2ePBnwKWQ721lYar3fnj DFJGRiiASQcGyUwATWZHwwbV0zX7vNLNHYsDzcy6s4BGh/ddRrBYv0z/F6P89+j/aZC9 11Kg== X-Gm-Message-State: AOAM532ERNxZvpArstiV4VBBVWZgCtChjaoMZfdnsjiLLL8FwcGnsAtF 3GEQbc2JEU+ePolINaDonVA= X-Google-Smtp-Source: ABdhPJwD4zfamuo2dCkKNAZTXaijPtPmtJJKGYhSU3ZEKVWqWpnQ5NhNKkaNB8gsT12UhfilxO4gJA== X-Received: by 2002:a17:90a:890a:: with SMTP id u10mr2353084pjn.88.1605582249440; Mon, 16 Nov 2020 19:04:09 -0800 (PST) Received: from localhost ([210.108.244.139]) by smtp.gmail.com with ESMTPSA id h16sm17115426pgd.62.2020.11.16.19.04.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Nov 2020 19:04:08 -0800 (PST) Date: Tue, 17 Nov 2020 12:04:06 +0900 From: YongHyeon PYUN To: Carsten =?iso-8859-1?Q?B=E4cker?= Cc: Hans Petter Selasky , Kristof Provost , freebsd-arm@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Problem with checksum offloading on RPi3 (PF + Jails involved) Message-ID: <20201117030406.GA45158@michelle> References: <5130ee46-5832-d4df-d774-c6bd32e10b30@gmx.de> <20201029213622.GM31099@funkthat.com> <55713894-A896-4F12-ABB9-93DFEB2F16B9@FreeBSD.org> <20201103045215.GA2524@michelle> <46d08198-530c-cb4b-efa8-4edaf89471c1@selasky.org> <4dfaa9a3-c085-8466-a6e4-19f988b5ed3d@selasky.org> <20201116011910.GB1941@michelle> <1245cbe5-9d2f-4808-f989-569ae7d57a8a@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1245cbe5-9d2f-4808-f989-569ae7d57a8a@gmx.de> X-Rspamd-Queue-Id: 4CZrPl0SzKz3Hq4 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2020 03:04:11 -0000 On Mon, Nov 16, 2020 at 12:54:25PM +0100, Carsten Bäcker wrote: [...] > i just did a test with your modification. > The good news is that the driver itself still works. Your test indicates my approach to improve RX validation works. Thanks a lot for testing. > The bad news is that it doesn't solve the problem. :-( > Let's dig further. Initially I thought pf(4) could be confused by mismatch of received packet length and IP datagram length. H/W does not strip padding bytes for short frame(< 60 bytes) and adds FCS bytes such that the minimum ethernet frame length is 64 bytes. When RX checksum offloading is enabled, the size will be 66 bytes. My patch tried to correct wrong packet length stored in mbuf. I think simple nping test would be helpful to narrow down the issue here. nping is bundled with nmap(ports/security/nmap). o Test patched smsc(4) with/without pf(4). - Disable RX checksum offloading and make sure all works as expected. - Run the following command on other system and see whether you can get ICMP port unreachable message from a box with smsc(4). 5555 is port number that listens on incoming UDP datagrams. #nping -c 1 --udp -p 5555 IPv4_addr_of_remote_host_with_smsc(4) #nping -c 1 --udp -p 5555 --data-length 100 IPv4_addr_of_remote_host_with_smsc(4) - Repeat the same test with RX checksum offloading enabled. If there is RX checksum mismatch you wouldn't get ICMP port unreachable message. You can even generate wrong checksummed UDP datagrams with --badsum option like the following. #nping -c 1 --udp -p 5555 --badsum IPv4_addr_of_remote_host_with_smsc(4) > I used the snapshot from 2020-10-29 as i already had an sdcard with that > image. > http://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/13.0/ > > Kernel was build from head + your patch. > FreeBSD generic 13.0-CURRENT FreeBSD 13.0-CURRENT #1 r367714M: Mon Nov > 16 08:03:24 UTC 2020 > root@sysbuild:/usr/obj/usr/src_head/arm64.aarch64/sys/GENERIC arm64 > > Log from smsc is attached. > The log shows my assumption on RX packet layout is correct. Thanks. > As the lack of hardware seems to be a problem... i may be able to > provide temporary access, incl. serial using a 2nd pi - but this will > take some time as i need to change the network-setup. > I think it's better to share nping test result first. From owner-freebsd-hackers@freebsd.org Tue Nov 17 04:38:44 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1FB9447F5AE; Tue, 17 Nov 2020 04:38:44 +0000 (UTC) (envelope-from carbaecker@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CZtVq5RfPz3Np1; Tue, 17 Nov 2020 04:38:43 +0000 (UTC) (envelope-from carbaecker@gmx.de) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1605587920; bh=KT3aYNH9X8qUHB8ExD3tTPoJJmZQh9TxX+EqB+9emH4=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=O9zOuPTrdYfe9yP/jBIS0xXGShPMCHxYlgQ2EskgSNAPuZeIdid/RprKWRA+cB674 RWTS9L6hJeE8qaOv7KPnVKLJHZEACVyeLp3mN8WJZB596BZc9tFb3QoupW/YfJsrLo Ekkce8xm9hACN/59WShYikxrNxyc00HeeorEYWPE= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.30] ([94.31.96.148]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MBUmD-1kYbNA3iRD-00D3Jx; Tue, 17 Nov 2020 05:38:39 +0100 Subject: Re: Problem with checksum offloading on RPi3 (PF + Jails involved) To: YongHyeon PYUN Cc: Hans Petter Selasky , Kristof Provost , freebsd-arm@freebsd.org, freebsd-hackers@freebsd.org References: <5130ee46-5832-d4df-d774-c6bd32e10b30@gmx.de> <20201029213622.GM31099@funkthat.com> <55713894-A896-4F12-ABB9-93DFEB2F16B9@FreeBSD.org> <20201103045215.GA2524@michelle> <46d08198-530c-cb4b-efa8-4edaf89471c1@selasky.org> <4dfaa9a3-c085-8466-a6e4-19f988b5ed3d@selasky.org> <20201116011910.GB1941@michelle> <1245cbe5-9d2f-4808-f989-569ae7d57a8a@gmx.de> <20201117030406.GA45158@michelle> From: =?UTF-8?Q?Carsten_B=c3=a4cker?= Message-ID: Date: Tue, 17 Nov 2020 05:38:38 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: <20201117030406.GA45158@michelle> Content-Type: multipart/mixed; boundary="------------05F385D1AB609A11B19CC179" Content-Language: de-DE X-Provags-ID: V03:K1:TUVAKnHdU3cum5HkQRANhCu0Sksfvt+c0UeCkBqbTs6jVTfYzhT 4enDVpyI6Rz2LLfY1PstZ9SojW9+0gU6e809uDynNTaVwdfFZOx0XBspqK7lzXi7LkQ1NP1 CIYAV0GbF+qjD4f2Gm7qatE2hyKcnvm4wQi4CirDjTlF1n9doiBu0dHKlMpObVn6JIxGOF6 FcAx9HsOT49hv+fJQM04g== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:dfLoGaM++ds=:DzlUFWtrDKZmFiEEBA98ro k1OpsvX07KvWsPdusLG8sS08UA0DWOHOSPexC1qby1H3cohslHUqjwaw3eg01V3KoizHYoE51 c7NPebfk4r7qxBQyCfEB0nxb6O5uX68RS8iWE8SI4Q+s0+XRqPV45AuR1GUknrxeyf/nq6xau FfhTtpRhzU0XGuaWfTyUbNhSGP6PWY6YcHKOHVHYMDFYjdqa/xS4y15S3qsglhkEDMmDzriJQ sbKOHhHkY5VmAoMvHbd8dYb94mhWrz0AI9wRsyRmxQqRrM6SRmgSICgbyHBjdJRjNopeJCIWu R+co60+GMJVpoBhaxipf36Mf+hZjdn8Py1a+cdz6tVLCPlz957hQS2uvL6nMq7f6YaYosmB8J 9PIGTtceiPVfkcD7bNqnth17YBGnTJqMeIwJC0F2FWJcLoygFcmVsvoeIJ9SMosKcTyOcsJJL 5+ZaumeLaFDHIKbLSkIJXq4jYfV0A9dYaC7kSOUWKoXvb2FyDa5A17UESgyZS+QkVkTCCxjXv NnP8cpzG+Wetpqz/rJUnsZBCCZDrV5KM0z/d2bGRphLVrxup+OYrxb/O0HwoN57yD4uco4LKr 9r0pgI1Lydk9xHt9s+GzX4gyEB2npRNZYYCdtD1hswF2ffWHLcsoNpklioYXLFpRaDZwhvHmL 63PrvxzY5xM0IeyZ6cTNJ5kDujL3EhB7k/ecQwAtdm1fGeVTbOYVUi1l+gbluSAzNCxiSCIGI ix3tFPNDfTpBRn1b3h/QMUU0NnKbVP4sBZJMxT1z2Tnz19mLx2WsXiQkC6mr0e4xn8qmmn9hz a7jDTdN6h2wNt52inuSylrMEBymWkmkSWbtbK9K1EqL302GVdTDOJX9VaNSyJl3G+YE0AbZst m+CI/QxAq3wy/RfJM0+Q== X-Rspamd-Queue-Id: 4CZtVq5RfPz3Np1 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2020 04:38:44 -0000 This is a multi-part message in MIME format. --------------05F385D1AB609A11B19CC179 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Am 17.11.2020 um 04:04 schrieb YongHyeon PYUN: > On Mon, Nov 16, 2020 at 12:54:25PM +0100, Carsten B=C3=A4cker wrote: > > [...] > >> i just did a test with your modification. >> The good news is that the driver itself still works. > Your test indicates my approach to improve RX validation works. > Thanks a lot for testing. > >> The bad news is that it doesn't solve the problem. :-( >> > Let's dig further. Initially I thought pf(4) could be confused by > mismatch of received packet length and IP datagram length. H/W > does not strip padding bytes for short frame(< 60 bytes) and adds > FCS bytes such that the minimum ethernet frame length is 64 bytes. > When RX checksum offloading is enabled, the size will be 66 bytes. > My patch tried to correct wrong packet length stored in mbuf. > > I think simple nping test would be helpful to narrow down the issue > here. nping is bundled with nmap(ports/security/nmap). > > o Test patched smsc(4) with/without pf(4). > - Disable RX checksum offloading and make sure all works as > expected. > - Run the following command on other system and see whether you > can get ICMP port unreachable message from a box with smsc(4). > 5555 is port number that listens on incoming UDP datagrams. > #nping -c 1 --udp -p 5555 IPv4_addr_of_remote_host_with_smsc(4) > > #nping -c 1 --udp -p 5555 --data-length 100 IPv4_addr_of_remote_hos= t_with_smsc(4) > > - Repeat the same test with RX checksum offloading enabled. > > If there is RX checksum mismatch you wouldn't get ICMP port > unreachable message. You can even generate wrong checksummed UDP > datagrams with --badsum option like the following. > #nping -c 1 --udp -p 5555 --badsum IPv4_addr_of_remote_host_with_smsc(4) > >> I used the snapshot from 2020-10-29 as i already had an sdcard with tha= t >> image. >> http://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/13.0/ >> >> Kernel was build from head + your patch. >> FreeBSD generic 13.0-CURRENT FreeBSD 13.0-CURRENT #1 r367714M: Mon Nov >> 16 08:03:24 UTC 2020 >> root@sysbuild:/usr/obj/usr/src_head/arm64.aarch64/sys/GENERIC arm64 >> >> Log from smsc is attached. >> > The log shows my assumption on RX packet layout is correct. > Thanks. > >> As the lack of hardware seems to be a problem... i may be able to >> provide temporary access, incl. serial using a 2nd pi - but this will >> take some time as i need to change the network-setup. >> > I think it's better to share nping test result first. Hello, i attached another set of log-files containing the output of the test using nping. The ICMP port unreachable message appeared in each case, but the paket loss changed to 100%. In addition i repeated the test with RXCSUM enabled after switching back to the unpatched kernel. Not sure if this helps. Regards, Carsten --------------05F385D1AB609A11B19CC179 Content-Type: text/plain; charset=UTF-8; name="nping_rxcsum_off.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="nping_rxcsum_off.txt" cm9vdEBnZW5lcmljOn4gIyBwZmN0bCAtc1IgOyBlY2hvIDsgaWZjb25maWcgdWUwCkRpc2Fi bGVkCgp1ZTA6IGZsYWdzPTg4NDM8VVAsQlJPQURDQVNULFJVTk5JTkcsU0lNUExFWCxNVUxU SUNBU1Q+IG1ldHJpYyAwIG10dSAxNTAwCiAgICAgICAgb3B0aW9ucz04MDAwODxWTEFOX01U VSxMSU5LU1RBVEU+CiAgICAgICAgZXRoZXIgYjg6Mjc6ZWI6NTU6N2U6NzAKICAgICAgICBp bmV0IDE5Mi4xNjguMTc4LjMgbmV0bWFzayAweGZmZmZmZjAwIGJyb2FkY2FzdCAxOTIuMTY4 LjE3OC4yNTUKICAgICAgICBtZWRpYTogRXRoZXJuZXQgYXV0b3NlbGVjdCAoMTAwYmFzZVRY IDxmdWxsLWR1cGxleD4pCiAgICAgICAgc3RhdHVzOiBhY3RpdmUKICAgICAgICBuZDYgb3B0 aW9ucz0yOTxQRVJGT1JNTlVELElGRElTQUJMRUQsQVVUT19MSU5LTE9DQUw+CgotLS0Kcm9v dEB0ZXN0LWFtZDY0On4gIyBucGluZyAtYyAxIC0tdWRwIC1wIDU1NTUgMTkyLjE2OC4xNzgu MwoKU3RhcnRpbmcgTnBpbmcgMC43LjgwICggaHR0cHM6Ly9ubWFwLm9yZy9ucGluZyApIGF0 IDIwMjAtMTEtMTcgMDU6MTEgQ0VUClNFTlQgKDAuMDA1MHMpIFVEUCAxOTIuMTY4LjE3OC4y OTo1MyA+IDE5Mi4xNjguMTc4LjM6NTU1NSB0dGw9NjQgaWQ9NTQyNjEgaXBsZW49MjgKUkNW RCAoMC4wMDU3cykgSUNNUCBbMTkyLjE2OC4xNzguMyA+IDE5Mi4xNjguMTc4LjI5IFBvcnQg dW5yZWFjaGFibGUgKHR5cGU9My9jb2RlPTMpIF0gSVAgW3R0bD02NCBpZD0yNjYxNSBpcGxl bj01NiBdCgpNYXggcnR0OiAwLjY2Mm1zIHwgTWluIHJ0dDogMC42NjJtcyB8IEF2ZyBydHQ6 IDAuNjYybXMKUmF3IHBhY2tldHMgc2VudDogMSAoMjhCKSB8IFJjdmQ6IDEgKDU2QikgfCBM b3N0OiAwICgwLjAwJSkKTnBpbmcgZG9uZTogMSBJUCBhZGRyZXNzIHBpbmdlZCBpbiAxLjAz IHNlY29uZHMKCi0tLQpyb290QHRlc3QtYW1kNjQ6fiAjIG5waW5nIC1jIDEgLS11ZHAgLXAg NTU1NSAtLWRhdGEtbGVuZ3RoIDEwMCAxOTIuMTY4LjE3OC4zCgpTdGFydGluZyBOcGluZyAw LjcuODAgKCBodHRwczovL25tYXAub3JnL25waW5nICkgYXQgMjAyMC0xMS0xNyAwNToxNCBD RVQKU0VOVCAoMC4wMDUxcykgVURQIDE5Mi4xNjguMTc4LjI5OjUzID4gMTkyLjE2OC4xNzgu Mzo1NTU1IHR0bD02NCBpZD01OTQwIGlwbGVuPTEyOApSQ1ZEICgwLjAxMzRzKSBJQ01QIFsx OTIuMTY4LjE3OC4zID4gMTkyLjE2OC4xNzguMjkgUG9ydCA1NTU1IHVucmVhY2hhYmxlICh0 eXBlPTMvY29kZT0zKSBdIElQIFt0dGw9NjQgaWQ9NTU1MzggaXBsZW49MTU2IF0KCk1heCBy dHQ6IDguMjY4bXMgfCBNaW4gcnR0OiA4LjI2OG1zIHwgQXZnIHJ0dDogOC4yNjhtcwpSYXcg cGFja2V0cyBzZW50OiAxICgxMjhCKSB8IFJjdmQ6IDEgKDE1NkIpIHwgTG9zdDogMCAoMC4w MCUpCk5waW5nIGRvbmU6IDEgSVAgYWRkcmVzcyBwaW5nZWQgaW4gMS4wNSBzZWNvbmRzCgot LS0Kcm9vdEB0ZXN0LWFtZDY0On4gIyBucGluZyAtYyAxIC0tdWRwIC1wIDU1NTUgLS1iYWRz dW0gMTkyLjE2OC4xNzguMwoKU3RhcnRpbmcgTnBpbmcgMC43LjgwICggaHR0cHM6Ly9ubWFw Lm9yZy9ucGluZyApIGF0IDIwMjAtMTEtMTcgMDU6MTUgQ0VUClNFTlQgKDAuMDA1MHMpIFVE UCAxOTIuMTY4LjE3OC4yOTo1MyA+IDE5Mi4xNjguMTc4LjM6NTU1NSB0dGw9NjQgaWQ9NDA1 NzIgaXBsZW49MjgKCk1heCBydHQ6IE4vQSB8IE1pbiBydHQ6IE4vQSB8IEF2ZyBydHQ6IE4v QQpSYXcgcGFja2V0cyBzZW50OiAxICgyOEIpIHwgUmN2ZDogMCAoMEIpIHwgTG9zdDogMSAo MTAwLjAwJSkKTnBpbmcgZG9uZTogMSBJUCBhZGRyZXNzIHBpbmdlZCBpbiAxLjA0IHNlY29u ZHMK --------------05F385D1AB609A11B19CC179 Content-Type: text/plain; charset=UTF-8; name="nping_rxcsum_on.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="nping_rxcsum_on.txt" cm9vdEBnZW5lcmljOn4gIyBwZmN0bCAtc1IgOyBlY2hvIDsgaWZjb25maWcgdWUwCkRpc2Fi bGVkCgp1ZTA6IGZsYWdzPTg4NDM8VVAsQlJPQURDQVNULFJVTk5JTkcsU0lNUExFWCxNVUxU SUNBU1Q+IG1ldHJpYyAwIG10dSAxNTAwCiAgICAgICAgb3B0aW9ucz04MDAwOTxSWENTVU0s VkxBTl9NVFUsTElOS1NUQVRFPgogICAgICAgIGV0aGVyIGI4OjI3OmViOjU1OjdlOjcwCiAg ICAgICAgaW5ldCAxOTIuMTY4LjE3OC4zIG5ldG1hc2sgMHhmZmZmZmYwMCBicm9hZGNhc3Qg MTkyLjE2OC4xNzguMjU1CiAgICAgICAgbWVkaWE6IEV0aGVybmV0IGF1dG9zZWxlY3QgKDEw MGJhc2VUWCA8ZnVsbC1kdXBsZXg+KQogICAgICAgIHN0YXR1czogYWN0aXZlCiAgICAgICAg bmQ2IG9wdGlvbnM9Mjk8UEVSRk9STU5VRCxJRkRJU0FCTEVELEFVVE9fTElOS0xPQ0FMPgoK LS0tCnJvb3RAdGVzdC1hbWQ2NDp+ICMgbnBpbmcgLWMgMSAtLXVkcCAtcCA1NTU1IDE5Mi4x NjguMTc4LjMKClN0YXJ0aW5nIE5waW5nIDAuNy44MCAoIGh0dHBzOi8vbm1hcC5vcmcvbnBp bmcgKSBhdCAyMDIwLTExLTE3IDA1OjE4IENFVApTRU5UICgwLjAwNTBzKSBVRFAgMTkyLjE2 OC4xNzguMjk6NTMgPiAxOTIuMTY4LjE3OC4zOjU1NTUgdHRsPTY0IGlkPTM2MjAyIGlwbGVu PTI4ClJDVkQgKDAuMDA1OHMpIElDTVAgWzE5Mi4xNjguMTc4LjMgPiAxOTIuMTY4LjE3OC4y OSBQb3J0IHVucmVhY2hhYmxlICh0eXBlPTMvY29kZT0zKSBdIElQIFt0dGw9NjQgaWQ9NTU1 MzkgaXBsZW49NTYgXQoKTWF4IHJ0dDogMC42NzJtcyB8IE1pbiBydHQ6IDAuNjcybXMgfCBB dmcgcnR0OiAwLjY3Mm1zClJhdyBwYWNrZXRzIHNlbnQ6IDEgKDI4QikgfCBSY3ZkOiAxICg1 NkIpIHwgTG9zdDogMCAoMC4wMCUpCk5waW5nIGRvbmU6IDEgSVAgYWRkcmVzcyBwaW5nZWQg aW4gMS4wMyBzZWNvbmRzCgotLS0Kcm9vdEB0ZXN0LWFtZDY0On4gIyBucGluZyAtYyAxIC0t dWRwIC1wIDU1NTUgLS1kYXRhLWxlbmd0aCAxMDAgMTkyLjE2OC4xNzguMwoKU3RhcnRpbmcg TnBpbmcgMC43LjgwICggaHR0cHM6Ly9ubWFwLm9yZy9ucGluZyApIGF0IDIwMjAtMTEtMTcg MDU6MTggQ0VUClNFTlQgKDAuMDA1MHMpIFVEUCAxOTIuMTY4LjE3OC4yOTo1MyA+IDE5Mi4x NjguMTc4LjM6NTU1NSB0dGw9NjQgaWQ9NTkwNzkgaXBsZW49MTI4ClJDVkQgKDAuMDA1OXMp IElDTVAgWzE5Mi4xNjguMTc4LjMgPiAxOTIuMTY4LjE3OC4yOSBQb3J0IDU1NTUgdW5yZWFj aGFibGUgKHR5cGU9My9jb2RlPTMpIF0gSVAgW3R0bD02NCBpZD01NTU0MCBpcGxlbj0xNTYg XQoKTWF4IHJ0dDogMC43OTltcyB8IE1pbiBydHQ6IDAuNzk5bXMgfCBBdmcgcnR0OiAwLjc5 OW1zClJhdyBwYWNrZXRzIHNlbnQ6IDEgKDEyOEIpIHwgUmN2ZDogMSAoMTU2QikgfCBMb3N0 OiAwICgwLjAwJSkKTnBpbmcgZG9uZTogMSBJUCBhZGRyZXNzIHBpbmdlZCBpbiAxLjA2IHNl Y29uZHMKCi0tLQpyb290QHRlc3QtYW1kNjQ6fiAjIG5waW5nIC1jIDEgLS11ZHAgLXAgNTU1 NSAtLWJhZHN1bSAxOTIuMTY4LjE3OC4zCgpTdGFydGluZyBOcGluZyAwLjcuODAgKCBodHRw czovL25tYXAub3JnL25waW5nICkgYXQgMjAyMC0xMS0xNyAwNToxOCBDRVQKU0VOVCAoMC4w MDUwcykgVURQIDE5Mi4xNjguMTc4LjI5OjUzID4gMTkyLjE2OC4xNzguMzo1NTU1IHR0bD02 NCBpZD05Mzg0IGlwbGVuPTI4CgpNYXggcnR0OiBOL0EgfCBNaW4gcnR0OiBOL0EgfCBBdmcg cnR0OiBOL0EKUmF3IHBhY2tldHMgc2VudDogMSAoMjhCKSB8IFJjdmQ6IDAgKDBCKSB8IExv c3Q6IDEgKDEwMC4wMCUpCk5waW5nIGRvbmU6IDEgSVAgYWRkcmVzcyBwaW5nZWQgaW4gMS4w NyBzZWNvbmRzCg== --------------05F385D1AB609A11B19CC179 Content-Type: text/plain; charset=UTF-8; name="nping_rxcsum_on_head.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="nping_rxcsum_on_head.txt" cm9vdEBnZW5lcmljOn4gIyB1bmFtZSAtYQpGcmVlQlNEIGdlbmVyaWMgMTMuMC1DVVJSRU5U IEZyZWVCU0QgMTMuMC1DVVJSRU5UICMwIGI5NDAzZDdhYWU4LWMyNTQwNzEobWFpbik6IFRo dSBPY3QgMjkgMTA6Mzg6MjkgVVRDIDIwMjAgICAgIHJvb3RAcmVsZW5nMS5ueWkuZnJlZWJz ZC5vcmc6L3Vzci9vYmovdXNyL3NyYy9hcm02NC5hYXJjaDY0L3N5cy9HRU5FUklDICBhcm02 NApyb290QGdlbmVyaWM6fiAjIHBmY3RsIC1zUiA7IGVjaG8gOyBpZmNvbmZpZyB1ZTAKRGlz YWJsZWQKCnVlMDogZmxhZ3M9ODg0MzxVUCxCUk9BRENBU1QsUlVOTklORyxTSU1QTEVYLE1V TFRJQ0FTVD4gbWV0cmljIDAgbXR1IDE1MDAKICAgICAgICBvcHRpb25zPTgwMDA5PFJYQ1NV TSxWTEFOX01UVSxMSU5LU1RBVEU+CiAgICAgICAgZXRoZXIgYjg6Mjc6ZWI6NTU6N2U6NzAK ICAgICAgICBpbmV0IDE5Mi4xNjguMTc4LjMgbmV0bWFzayAweGZmZmZmZjAwIGJyb2FkY2Fz dCAxOTIuMTY4LjE3OC4yNTUKICAgICAgICBtZWRpYTogRXRoZXJuZXQgYXV0b3NlbGVjdCAo MTAwYmFzZVRYIDxmdWxsLWR1cGxleD4pCiAgICAgICAgc3RhdHVzOiBhY3RpdmUKICAgICAg ICBuZDYgb3B0aW9ucz0yOTxQRVJGT1JNTlVELElGRElTQUJMRUQsQVVUT19MSU5LTE9DQUw+ CgotLS0Kcm9vdEB0ZXN0LWFtZDY0On4gIyBucGluZyAtYyAxIC0tdWRwIC1wIDU1NTUgMTky LjE2OC4xNzguMwoKU3RhcnRpbmcgTnBpbmcgMC43LjgwICggaHR0cHM6Ly9ubWFwLm9yZy9u cGluZyApIGF0IDIwMjAtMTEtMTcgMDU6MjQgQ0VUClNFTlQgKDAuMDA1MHMpIFVEUCAxOTIu MTY4LjE3OC4yOTo1MyA+IDE5Mi4xNjguMTc4LjM6NTU1NSB0dGw9NjQgaWQ9MjcyMDIgaXBs ZW49MjgKUkNWRCAoMC4wMDYzcykgSUNNUCBbMTkyLjE2OC4xNzguMyA+IDE5Mi4xNjguMTc4 LjI5IFBvcnQgdW5yZWFjaGFibGUgKHR5cGU9My9jb2RlPTMpIF0gSVAgW3R0bD02NCBpZD02 MzY1OCBpcGxlbj01NiBdCgpNYXggcnR0OiAxLjI0M21zIHwgTWluIHJ0dDogMS4yNDNtcyB8 IEF2ZyBydHQ6IDEuMjQzbXMKUmF3IHBhY2tldHMgc2VudDogMSAoMjhCKSB8IFJjdmQ6IDEg KDU2QikgfCBMb3N0OiAwICgwLjAwJSkKTnBpbmcgZG9uZTogMSBJUCBhZGRyZXNzIHBpbmdl ZCBpbiAxLjAyIHNlY29uZHMKCi0tLQpyb290QHRlc3QtYW1kNjQ6fiAjIG5waW5nIC1jIDEg LS11ZHAgLXAgNTU1NSAtLWRhdGEtbGVuZ3RoIDEwMCAxOTIuMTY4LjE3OC4zCgpTdGFydGlu ZyBOcGluZyAwLjcuODAgKCBodHRwczovL25tYXAub3JnL25waW5nICkgYXQgMjAyMC0xMS0x NyAwNToyNCBDRVQKU0VOVCAoMC4wMDUwcykgVURQIDE5Mi4xNjguMTc4LjI5OjUzID4gMTky LjE2OC4xNzguMzo1NTU1IHR0bD02NCBpZD02NDc4NiBpcGxlbj0xMjgKUkNWRCAoMC4wMDU4 cykgSUNNUCBbMTkyLjE2OC4xNzguMyA+IDE5Mi4xNjguMTc4LjI5IFBvcnQgNTU1NSB1bnJl YWNoYWJsZSAodHlwZT0zL2NvZGU9MykgXSBJUCBbdHRsPTY0IGlkPTU2NTQyIGlwbGVuPTE1 NiBdCgpNYXggcnR0OiAwLjc0MW1zIHwgTWluIHJ0dDogMC43NDFtcyB8IEF2ZyBydHQ6IDAu NzQxbXMKUmF3IHBhY2tldHMgc2VudDogMSAoMTI4QikgfCBSY3ZkOiAxICgxNTZCKSB8IExv c3Q6IDAgKDAuMDAlKQpOcGluZyBkb25lOiAxIElQIGFkZHJlc3MgcGluZ2VkIGluIDEuMDUg c2Vjb25kcwoKLS0tCnJvb3RAdGVzdC1hbWQ2NDp+ICMgbnBpbmcgLWMgMSAtLXVkcCAtcCA1 NTU1IC0tYmFkc3VtIDE5Mi4xNjguMTc4LjMKClN0YXJ0aW5nIE5waW5nIDAuNy44MCAoIGh0 dHBzOi8vbm1hcC5vcmcvbnBpbmcgKSBhdCAyMDIwLTExLTE3IDA1OjI0IENFVApTRU5UICgw LjAwNTBzKSBVRFAgMTkyLjE2OC4xNzguMjk6NTMgPiAxOTIuMTY4LjE3OC4zOjU1NTUgdHRs PTY0IGlkPTMyMDQ2IGlwbGVuPTI4CgpNYXggcnR0OiBOL0EgfCBNaW4gcnR0OiBOL0EgfCBB dmcgcnR0OiBOL0EKUmF3IHBhY2tldHMgc2VudDogMSAoMjhCKSB8IFJjdmQ6IDAgKDBCKSB8 IExvc3Q6IDEgKDEwMC4wMCUpCk5waW5nIGRvbmU6IDEgSVAgYWRkcmVzcyBwaW5nZWQgaW4g MS4wNyBzZWNvbmRzCg== --------------05F385D1AB609A11B19CC179-- From owner-freebsd-hackers@freebsd.org Wed Nov 18 04:49:02 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BB4EF2E1A4B; Wed, 18 Nov 2020 04:49:02 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CbVhF5yKkz4fGP; Wed, 18 Nov 2020 04:49:01 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by mail-pg1-x532.google.com with SMTP id f18so338719pgi.8; Tue, 17 Nov 2020 20:49:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=lWgkZLoGYC/X87gAddC5fWYbihrFilTTEXGoskKfDeA=; b=jfcp2/2OM/OkrJPs8fAEldQ1QM7ircIdbYHAglFVW1ktsyJyI0yrLPwTdjcmyfcdA9 g3f3WFS0H9yt/3dLEsDskLfp+vuLuLslTJXRa7kH9kerTDkcLFxGJnltgji15tDYjjvO unRDv6C17xdrVpPT2huMvFPSEYAmleftAjAbvRAE4YnQjT7q/0RyabHQdz8ChP9rFa6L OV28+Ws3cgbN+GaC4BLbTHOtyBGgOeXn5cf6qXZ7GFsqBZZxBOn0/6WSjxfVHdZJKa+R T2TY54zvQsvXIMKmC0eXgvThWDEoPMEddgfYJJ1ceiu2O+iZakkzTAV13WBIGTOTe7jB B8oA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=lWgkZLoGYC/X87gAddC5fWYbihrFilTTEXGoskKfDeA=; b=ixZRE2/V7+M+r58LEvTU9CBuC4L+W+Qx0Rzjh1Ny4XT5o+MelHNJpqY2Bpri3ZFJi/ ImrGEe8ar5WUsjWQvqT57Y+eq4A515I71VhRMzJz0yj+NnMSig+uoohf+QwzKo+RJ8pa mn8trg7Zt+EQ5RYQmnaNK0x+HMWzr8wYv3jkzVJ4t/qktlomXRp5xL7J8E42h2bAeEEq 5vDiIXgXqST98DC4ym/zoLGyMLpLHllCokv2bvNjX2ci/Ka0s4BmkxJerzpEv+XBVY+5 CrJc4P+NCNjg7eQ+6AlL9M6DYr4qRqpO8Q7m5vlyPBputoWbb00850ccLQf9qiSTHXH8 6ZZg== X-Gm-Message-State: AOAM531QJUpYYgsjDz3RblH4oGcUK2OLsXr+qdbU7Ad3lbjLT9oGns+X gF/CWpl1g21Hn5ISkfjwDkwAzZ0vk/o= X-Google-Smtp-Source: ABdhPJxrEZ0fe5ek01IS2g2WaOgW/C/1oy6poTP7Kn4tuA2WoKXJbd5rIFXbxzraToPJ/VKPJ27Vew== X-Received: by 2002:a63:2a83:: with SMTP id q125mr6361026pgq.84.1605674940545; Tue, 17 Nov 2020 20:49:00 -0800 (PST) Received: from localhost ([210.108.244.139]) by smtp.gmail.com with ESMTPSA id m9sm22969285pfh.94.2020.11.17.20.48.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Nov 2020 20:48:59 -0800 (PST) Date: Wed, 18 Nov 2020 13:48:57 +0900 From: YongHyeon PYUN To: Carsten =?iso-8859-1?Q?B=E4cker?= Cc: Hans Petter Selasky , Kristof Provost , freebsd-arm@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Problem with checksum offloading on RPi3 (PF + Jails involved) Message-ID: <20201118044857.GA1974@michelle> References: <20201029213622.GM31099@funkthat.com> <55713894-A896-4F12-ABB9-93DFEB2F16B9@FreeBSD.org> <20201103045215.GA2524@michelle> <46d08198-530c-cb4b-efa8-4edaf89471c1@selasky.org> <4dfaa9a3-c085-8466-a6e4-19f988b5ed3d@selasky.org> <20201116011910.GB1941@michelle> <1245cbe5-9d2f-4808-f989-569ae7d57a8a@gmx.de> <20201117030406.GA45158@michelle> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 4CbVhF5yKkz4fGP X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=jfcp2/2O; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of pyunyh@gmail.com designates 2607:f8b0:4864:20::532 as permitted sender) smtp.mailfrom=pyunyh@gmail.com X-Spamd-Result: default: False [-3.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FREEMAIL_TO(0.00)[gmx.de]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[2607:f8b0:4864:20::532:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[2607:f8b0:4864:20::532:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::532:from]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm,freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2020 04:49:02 -0000 On Tue, Nov 17, 2020 at 05:38:38AM +0100, Carsten Bäcker wrote: [...] > i attached another set of log-files containing the output of the test > using nping. > The ICMP port unreachable message appeared in each case, but the paket > loss changed to 100%. That came from 3rd nping test with --badsum option and that's normal. If I read attached log-files correctly all worked as expected. I don't know what pf rulesets you used. Did you use the same pf ruleset + jail with patched smsc(4)? If you didn't yet could you test it again and let me know nping output? From owner-freebsd-hackers@freebsd.org Wed Nov 18 07:13:39 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 90FC12E5122; Wed, 18 Nov 2020 07:13:39 +0000 (UTC) (envelope-from rajfbsd@gmail.com) Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::22f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CbYv63KxNz4lxC; Wed, 18 Nov 2020 07:13:38 +0000 (UTC) (envelope-from rajfbsd@gmail.com) Received: by mail-oi1-x22f.google.com with SMTP id d9so1166093oib.3; Tue, 17 Nov 2020 23:13:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=R/2r2GAn1M0Sooc530sL6kXaFRJYwYUK1VxCizp7Zws=; b=gxWr3zTc8ucz71SasYepbpP8pJoc7BANSLvEYEHvcBsXHhii477f21Z9XqyWsu1x0u iex8LZSyYY/E/DRcu4HmrT6O1rGBMj9PdYRfm2lJhERIFUPAQUvp+tZLYPsAUNwhCBM/ Op/jQt81NE7mktGEr44bBnx94Uv6defyeaiuLaWPYojHK+G0SFLz5vftZfd10qM7nhB3 PMb8SfwUfWGRJF/o0UOY7NFFDfRSfdeWaRGR9AkiRhh2P33reWXKPrxbQmMpXVU4fy1l lCAlYYiRANkCcRFgdZwR0KrCyDZljCYoI22NHm/cNifkB8/M1mQ4cSjRCEHq0vVjPgcU GDKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=R/2r2GAn1M0Sooc530sL6kXaFRJYwYUK1VxCizp7Zws=; b=aQOrYEp+vOKIZNtwpk9puXLDlLIMvTgpPl8YbnMqsZ6AEZQLrVncc4SGcCoUKRtjJk bq2Y6dj0+H7Xth7AyQUq9rka0aS5JcEYLjMXD+cBVf5VUOWyi7f7rHroP6T9P+LMuJAK siMUnWN9L5bO2OFyBI0PGcxfotZGUHblsAwd+L3nDH/Afd0cx1zWzCmEyx4Qkmc5ArPQ 8DmC8IUBWywv2S2bv65eWS8TavTSLKqXVXkgFZQUVyRHEzVhaWWyTTOxdU1yOU6qW/Aw plDP8GghK30o3FUvRARdlvBp7UGujQ4d81iAbdPB1r7rU5qHlv8IgOxOOi2P9Ywil1wm GibA== X-Gm-Message-State: AOAM530KMoNDoJtjFpAXDpy+8XzbqqzOqRMQ9PfOGBroG9Po2mDb2kae GngsRqATA1Laoft/xXPf5k2RQVj8gFtzNOLjI/R1ty8V X-Google-Smtp-Source: ABdhPJxXfaRWI4A1gYBm1BOKyhbFBhqPvFDzDU2vc7K2a24cF4tYAlDtp0+bNnpYTOUtTzYfdIt0Bc/d7Q/5FLXiSE4= X-Received: by 2002:aca:6548:: with SMTP id j8mr1932453oiw.109.1605683616785; Tue, 17 Nov 2020 23:13:36 -0800 (PST) MIME-Version: 1.0 From: Rajesh Kumar Date: Wed, 18 Nov 2020 12:43:23 +0530 Message-ID: Subject: Netmap bridge not working with 10G Ethernet ports To: freebsd-net@freebsd.org, FreeBSD Hackers X-Rspamd-Queue-Id: 4CbYv63KxNz4lxC X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=gxWr3zTc; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rajfbsd@gmail.com designates 2607:f8b0:4864:20::22f as permitted sender) smtp.mailfrom=rajfbsd@gmail.com X-Spamd-Result: default: False [-3.98 / 15.00]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2607:f8b0:4864:20::22f:from]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; SPAMHAUS_ZRD(0.00)[2607:f8b0:4864:20::22f:from:127.0.2.255]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::22f:from]; NEURAL_HAM_SHORT(-0.98)[-0.978]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-net,freebsd-hackers]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2020 07:13:39 -0000 Hi, I am testing a 10G Network driver with Netmap "bridge" utility, where it doesn't seem to work. Here is my setup details. *System under Test:* Running FreeBSD CURRENT. Has two inbuilt 10G NIC ports. *System 1:* Running Ubuntu, whose network port is connected to Port1 of System Under Test *System 2:* Running FreeBSD CURRENT, whose network port is connected to Port 0 of System Under Test. Bridged the Port0 and Port1 of System Under Test using the Netmap "bridge" utility. Able to see interfaces coming up active and Link UP. # bridge -c -v -i netmap:ax0 -i netmap:ax1 Then tried pinging from System 1 to System 2. It fails. *Observations:* 1. ARP request from System 1 goes to bridge port 1 (netmap_rxsync) and then forwarded to port 0 (netmap_txsync) 2. ARP request is received in System 2 (via bridge port 0) and ARP reply is being sent from System 2. 3. ARP reply from System 2 seems to be not reaching bridge port 0 to get forwarded to bridge 1 and hence to System 1. 4. Above 3 steps happen 3 times for ARP resolution cycle and then fails. Hence the ping fails. On Debugging, when the ARP reply is being sent from System 2, I don't see any interrupt triggered on the bridge port 0 in system under test. Netstat in system under test, doesn't show any receive or drop counters incremented. But as I understand netstat capture the stats above the netmap stack. Hence not reflecting the counts. *Note:* a) I tried with another vendor 10G NIC card. It behaves the same way. So this issue doesn't seem to be generic and not hardware specific. b) Trying with another vendor 1G NIC card, things are working. So not sure, what makes a difference here. The ports in System 1 and System 2 are USB attached Ethernet capable of maximum speed of 1G. So does connecting 1G to 10G bridge ports is having any impact? c) We have verified the same 10G driver with pkt-gen utility and things are working. Facing issue only when using "bridge" utility. So, wondering how the ARP reply packet is getting lost here. Any ideas to debug? Thanks, Rajesh. From owner-freebsd-hackers@freebsd.org Wed Nov 18 09:27:50 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A966E2E84FE for ; Wed, 18 Nov 2020 09:27:50 +0000 (UTC) (envelope-from nkoch@demig.de) Received: from exch.demig.de (exch.demig.de [130.180.89.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "srv-inet-2.demig.intra", Issuer "demig Prozessautomatisierung GmbH WebAdmin CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Cbcsx3sPnz4scy for ; Wed, 18 Nov 2020 09:27:49 +0000 (UTC) (envelope-from nkoch@demig.de) Received: from [192.168.148.248] (port=48403 helo=SRV-FS-2.Demig.intra) by exch.demig.de with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1kfJkP-00053y-06 for freebsd-hackers@freebsd.org; Wed, 18 Nov 2020 10:27:29 +0100 Received: from [192.168.148.216] (192.168.148.216) by SRV-FS-2 (192.168.148.248) with Microsoft SMTP Server (TLS) id 14.3.468.0; Wed, 18 Nov 2020 10:27:25 +0100 X-CTCH-RefID: str=0001.0A09020C.5FB4E901.002F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 To: From: Norbert Koch Subject: pci function level reset Message-ID: <8a8c7813-18fc-6dd3-28b3-803e48f89131@demig.de> Date: Wed, 18 Nov 2020 10:27:19 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-C2ProcessedOrg: e1e98c77-ec17-4cb1-9b24-fe57656077ed X-Rspamd-Queue-Id: 4Cbcsx3sPnz4scy X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of nkoch@demig.de designates 130.180.89.86 as permitted sender) smtp.mailfrom=nkoch@demig.de X-Spamd-Result: default: False [-3.30 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[130.180.89.86:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[demig.de]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[130.180.89.86:from:127.0.2.255]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:6830, ipnet:130.180.64.0/18, country:AT]; MIME_TRACE(0.00)[0:+]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2020 09:27:50 -0000 Hello. I am running 12.1 on an embedded board which is equipped with an intel gbit ethernet controller (Intel PRO/1000, em driver). Either the ethernet controller or the bios has a bug, which the board manufacturer confirmed. After soft reboot gbit ethernet sometimes stops working while 100/10mbit are ok. Only after power down gbit works again (mostly). As they only support windows and linux, their "fix" is writing a '1' to /sys/bus/pci/devices/$dev/reset. They say this is a "function level reset", whatever this means. Is there any way (e.g. using pciconf) to do this under FreeBSD? Thank you. *********************************************************************** * demig Prozessautomatisierung GmbH * demig Anlagentechnik GmbH * * * * * Anschrift: Haardtstrasse 40 * Haardtstrasse 40 * * D-57076 Siegen * D-57076 Siegen * * Registergericht: Siegen HRB 2819 * Siegen HRB 5532 * * Geschaeftsfuehrer: Joachim Herbst, * Joachim Herbst, * * Winfried Held * Winfried Held * * Telefon: +49 271 772020 * +49 271 772020 * * Telefax: +49 271 74704 * +49 271 74704 * * E-Mail: info@demig.de * at@demig.de * * http://www.demig.de * http://www.demig.de * *********************************************************************** From owner-freebsd-hackers@freebsd.org Wed Nov 18 09:47:12 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C3DB72E9032; Wed, 18 Nov 2020 09:47:12 +0000 (UTC) (envelope-from carbaecker@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CbdJJ3K0Mz4v6W; Wed, 18 Nov 2020 09:47:12 +0000 (UTC) (envelope-from carbaecker@gmx.de) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1605692829; bh=Uqdun0mAdV+Dp+v+XGzrm9CXH/LJny1uiJaynezuoDo=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=QRD48PuW2xYcMehSYK7VXhiWi4Xs6UENyzBY23uuPrmZG2kUdewnDaFFKbb2dL0V0 230spPGwp0jto5EFDjuNnuTh9TfspdTL5WM34V8+y/5LIxXvooXkUK/oYVoDVDHCeo bv4wEgvA69us3SreXa98Itfk4g5ouH0Vp0W8inA8= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.30] ([94.31.96.148]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MBlxW-1kXZlA3TFk-00C6Hi; Wed, 18 Nov 2020 10:47:08 +0100 Subject: Re: Problem with checksum offloading on RPi3 (PF + Jails involved) To: YongHyeon PYUN Cc: Hans Petter Selasky , Kristof Provost , freebsd-arm@freebsd.org, freebsd-hackers@freebsd.org References: <20201029213622.GM31099@funkthat.com> <55713894-A896-4F12-ABB9-93DFEB2F16B9@FreeBSD.org> <20201103045215.GA2524@michelle> <46d08198-530c-cb4b-efa8-4edaf89471c1@selasky.org> <4dfaa9a3-c085-8466-a6e4-19f988b5ed3d@selasky.org> <20201116011910.GB1941@michelle> <1245cbe5-9d2f-4808-f989-569ae7d57a8a@gmx.de> <20201117030406.GA45158@michelle> <20201118044857.GA1974@michelle> From: =?UTF-8?Q?Carsten_B=c3=a4cker?= Message-ID: Date: Wed, 18 Nov 2020 10:47:08 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: <20201118044857.GA1974@michelle> Content-Type: multipart/mixed; boundary="------------6D413B37D402893C04AB9EB3" Content-Language: de-DE X-Provags-ID: V03:K1:yyKAiiDWtMhcfQegddt3i/AupREagZ4a0YSK5Qe+WvQh7NeNfQO Ao/o0Y984Gug48WWmxLHxqw6DLOZ7RYn5f74xQhceVuJDBxEocUUja3y87yGM4N6twq5HGH a1vQC+X6shN1s6EpKjKlCC4OZZ47JMVhlEOOO5KXFpt9ktJCJFPqyj8kIVnLRq2+E7TlgvX U4AUYsZYZF1esqkHAk0Ew== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:68MJME7+ZoY=:Iow7Dxt4qjsoMVTc59m5Ov 1VWMPa5sAn9YVbG/nldtEKNrYekEeLEdqxxEgcfg1WYMx1GQ5gsS2eZ2DBSWfa4kbRZenWdoc kfsI4pU3uu8U0a5pw4O/myok63fLnbetWhjBXe4F4Tnl1mNp8dSlKRDY/Z4RdXY45GcBELNDE 73GRgScClXseT9d6emY+dUog5VLqKrJiEt5SGha0yWwK1kQ+Oen+SxuXIb3NtJiG42Kl16M1y C4fvDJlt0DtFlOt1b9csi0N02+LJ3OMAyc7oM1xf9EDw9hsVPDtmROmDi4VwGV4QPanLIiLlZ s6ubLPyFt/oBjHyVouVpinBS0KecCvgY7nX07l+6I65aI8oStordXWZUNXioL08aS+ZlGwUV4 mBoikJ1058G8simWOPnPGHlhUfD/ZPzcVCJoOCFzvwnOEW2aVgxLsWH9eHGohopA8T12Dct7W F8kRzi5fFZX48gpCKOhNH/t2uEFKjY3VtjJ2ToBmeoDmJ3vo93BNFcS2yZoieN5Od6W1ifhBf xxWBcql7Ffg5Ubzlu3W0bhnm5ojSA7CIOETTyoiu9noBzHM7qfrABP71hcBP+OLRbIMW04qG8 WE9iyBY4zMeVix3i2AU2dxXsr6JlMxPP1RiX0dfEM58+vZGMtPpTlU3UtTN7Zbyca6IftsbSQ 6O0acdeaYDdJhRoxibl9u/hcGSt5Fcc/12VBWewaWmq3EpWM+yvhTEBdW5HSgoSvJUocoE/s7 rUgJcxU2qQHVL+OVR+iqZrC3OYphlZ2GjMD4kVF2FOftLLjJvES6LDZXRN8KfgK7PpJN3PJmO yywdhNj0kJ3AK6jtkAzAecsilRFIlETHnPeyPs9WbuLIMGiI8qxmm07/XINlVBqFkiN6kXAoP U0vH7AO9tWLaaVq57yuQ== X-Rspamd-Queue-Id: 4CbdJJ3K0Mz4v6W X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2020 09:47:12 -0000 This is a multi-part message in MIME format. --------------6D413B37D402893C04AB9EB3 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Am 18.11.2020 um 05:48 schrieb YongHyeon PYUN: > On Tue, Nov 17, 2020 at 05:38:38AM +0100, Carsten B=C3=A4cker wrote: > > [...] > >> i attached another set of log-files containing the output of the test >> using nping. >> The ICMP port unreachable message appeared in each case, but the paket >> loss changed to 100%. > That came from 3rd nping test with --badsum option and that's normal. > If I read attached log-files correctly all worked as expected. > I don't know what pf rulesets you used. Did you use the same pf > ruleset + jail with patched smsc(4)? If you didn't yet could you > test it again and let me know nping output? Sorry, that's my fault - i overlooked your request for a test with pf enabled. The example-ruleset is attached again. I added a line to allow the incoming ping to 5555. I don't see a difference until i enable the redirection to the jail which makes the packet with extended data-length fail. Once i disable RXCSUM it works. Regards, Carsten --------------6D413B37D402893C04AB9EB3 Content-Type: text/plain; charset=UTF-8; name="pf_nping.conf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pf_nping.conf" ZXh0X2lmID0gInVlMCIKCnd3d3B1YmxpY2phaWwgPSAxMC4wLjAuMgoKc2V0IGJsb2NrLXBv bGljeSByZXR1cm4Kc2V0IHNraXAgb24gbG8wCnNldCBza2lwIG9uIGxvMQoKdGFibGUgPGph aWxzPiBwZXJzaXN0CgpuYXQgb24gJGV4dF9pZiBmcm9tIHsgJHd3d3B1YmxpY2phaWwgfSB0 byBhbnkgLT4gKCRleHRfaWYpCiNyZHIgb24gJGV4dF9pZiBpbmV0IHByb3RvIHVkcCBmcm9t IGFueSB0byAoJGV4dF9pZikgcG9ydCA1NTU1IC0+ICR3d3dwdWJsaWNqYWlsCgpibG9jayBp biBhbGwKCnBhc3MgaW4gaW5ldCBwcm90byBpY21wIGFsbCBpY21wLXR5cGUgZWNob3JlcQpw YXNzIGluIGluZXQgcHJvdG8gdGNwIHRvIHBvcnQgeyBzc2ggfQpwYXNzIGluIGluZXQgcHJv dG8gdWRwIHRvIHBvcnQgeyA1NTU1IH0KCnBhc3Mgb3V0IGFsbAoK --------------6D413B37D402893C04AB9EB3 Content-Type: text/plain; charset=UTF-8; name="nping_rxcsum_on_pf_host.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="nping_rxcsum_on_pf_host.txt" cm9vdEBnZW5lcmljOn4gIyBwZmN0bCAtc3IgOyBlY2hvIDsgcGZjdGwgLXNuIDsgZWNobyA7 IGlmY29uZmlnIHVlMCA7IGVjaG8gOyB1bmFtZSAtdgpibG9jayByZXR1cm4gaW4gYWxsCnBh c3MgaW4gaW5ldCBwcm90byBpY21wIGFsbCBpY21wLXR5cGUgZWNob3JlcSBrZWVwIHN0YXRl CnBhc3MgaW4gaW5ldCBwcm90byB0Y3AgZnJvbSBhbnkgdG8gYW55IHBvcnQgPSBzc2ggZmxh Z3MgUy9TQSBrZWVwIHN0YXRlCnBhc3MgaW4gaW5ldCBwcm90byB1ZHAgZnJvbSBhbnkgdG8g YW55IHBvcnQgPSBycGxheSBrZWVwIHN0YXRlCnBhc3Mgb3V0IGFsbCBmbGFncyBTL1NBIGtl ZXAgc3RhdGUKCm5hdCBvbiB1ZTAgaW5ldCBmcm9tIDEwLjAuMC4yIHRvIGFueSAtPiAodWUw KSByb3VuZC1yb2JpbgoKdWUwOiBmbGFncz04ODQzPFVQLEJST0FEQ0FTVCxSVU5OSU5HLFNJ TVBMRVgsTVVMVElDQVNUPiBtZXRyaWMgMCBtdHUgMTUwMAogICAgICAgIG9wdGlvbnM9ODAw MDk8UlhDU1VNLFZMQU5fTVRVLExJTktTVEFURT4KICAgICAgICBldGhlciBiODoyNzplYjo1 NTo3ZTo3MAogICAgICAgIGluZXQgMTkyLjE2OC4xNzguMyBuZXRtYXNrIDB4ZmZmZmZmMDAg YnJvYWRjYXN0IDE5Mi4xNjguMTc4LjI1NQogICAgICAgIG1lZGlhOiBFdGhlcm5ldCBhdXRv c2VsZWN0ICgxMDBiYXNlVFggPGZ1bGwtZHVwbGV4PikKICAgICAgICBzdGF0dXM6IGFjdGl2 ZQogICAgICAgIG5kNiBvcHRpb25zPTI5PFBFUkZPUk1OVUQsSUZESVNBQkxFRCxBVVRPX0xJ TktMT0NBTD4KCkZyZWVCU0QgMTMuMC1DVVJSRU5UICMxIHIzNjc3MTRNOiBNb24gTm92IDE2 IDA4OjAzOjI0IFVUQyAyMDIwICAgICByb290QHN5c2J1aWxkOi91c3Ivb2JqL3Vzci9zcmNf aGVhZC9hcm02NC5hYXJjaDY0L3N5cy9HRU5FUklDCgotLS0Kcm9vdEB0ZXN0LWFtZDY0On4g IyBucGluZyAtYyAxIC0tdWRwIC1wIDU1NTUgMTkyLjE2OC4xNzguMwoKU3RhcnRpbmcgTnBp bmcgMC43LjgwICggaHR0cHM6Ly9ubWFwLm9yZy9ucGluZyApIGF0IDIwMjAtMTEtMTggMDk6 MzAgQ0VUClNFTlQgKDAuMDA0OHMpIFVEUCAxOTIuMTY4LjE3OC4yOTo1MyA+IDE5Mi4xNjgu MTc4LjM6NTU1NSB0dGw9NjQgaWQ9MTI4MDEgaXBsZW49MjgKUkNWRCAoMC4wMDU3cykgSUNN UCBbMTkyLjE2OC4xNzguMyA+IDE5Mi4xNjguMTc4LjI5IFBvcnQgdW5yZWFjaGFibGUgKHR5 cGU9My9jb2RlPTMpIF0gSVAgW3R0bD02NCBpZD0zNjAwMSBpcGxlbj01NiBdCgpNYXggcnR0 OiAwLjgyM21zIHwgTWluIHJ0dDogMC44MjNtcyB8IEF2ZyBydHQ6IDAuODIzbXMKUmF3IHBh Y2tldHMgc2VudDogMSAoMjhCKSB8IFJjdmQ6IDEgKDU2QikgfCBMb3N0OiAwICgwLjAwJSkK TnBpbmcgZG9uZTogMSBJUCBhZGRyZXNzIHBpbmdlZCBpbiAxLjA1IHNlY29uZHMKCi0tLQpy b290QHRlc3QtYW1kNjQ6fiAjIG5waW5nIC1jIDEgLS11ZHAgLXAgNTU1NSAtLWRhdGEtbGVu Z3RoIDEwMCAxOTIuMTY4LjE3OC4zCgpTdGFydGluZyBOcGluZyAwLjcuODAgKCBodHRwczov L25tYXAub3JnL25waW5nICkgYXQgMjAyMC0xMS0xOCAwOTozMiBDRVQKU0VOVCAoMC4wMDQ4 cykgVURQIDE5Mi4xNjguMTc4LjI5OjUzID4gMTkyLjE2OC4xNzguMzo1NTU1IHR0bD02NCBp ZD00MDUxMiBpcGxlbj0xMjgKUkNWRCAoMC4wMDU4cykgSUNNUCBbMTkyLjE2OC4xNzguMyA+ IDE5Mi4xNjguMTc4LjI5IFBvcnQgNTU1NSB1bnJlYWNoYWJsZSAodHlwZT0zL2NvZGU9Mykg XSBJUCBbdHRsPTY0IGlkPTU2MjM1IGlwbGVuPTE1NiBdCgpNYXggcnR0OiAwLjgzOW1zIHwg TWluIHJ0dDogMC44MzltcyB8IEF2ZyBydHQ6IDAuODM5bXMKUmF3IHBhY2tldHMgc2VudDog MSAoMTI4QikgfCBSY3ZkOiAxICgxNTZCKSB8IExvc3Q6IDAgKDAuMDAlKQpOcGluZyBkb25l OiAxIElQIGFkZHJlc3MgcGluZ2VkIGluIDEuMDMgc2Vjb25kcwo= --------------6D413B37D402893C04AB9EB3 Content-Type: text/plain; charset=UTF-8; name="nping_rxcsum_on_pf_jail.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="nping_rxcsum_on_pf_jail.txt" cm9vdEBnZW5lcmljOn4gIyBwZmN0bCAtc3IgOyBlY2hvIDsgcGZjdGwgLXNuIDsgZWNobyA7 IGlmY29uZmlnIHVlMCA7IGVjaG8gOyB1bmFtZSAtdgpibG9jayByZXR1cm4gaW4gYWxsCnBh c3MgaW4gaW5ldCBwcm90byBpY21wIGFsbCBpY21wLXR5cGUgZWNob3JlcSBrZWVwIHN0YXRl CnBhc3MgaW4gaW5ldCBwcm90byB0Y3AgZnJvbSBhbnkgdG8gYW55IHBvcnQgPSBzc2ggZmxh Z3MgUy9TQSBrZWVwIHN0YXRlCnBhc3MgaW4gaW5ldCBwcm90byB1ZHAgZnJvbSBhbnkgdG8g YW55IHBvcnQgPSBycGxheSBrZWVwIHN0YXRlCnBhc3Mgb3V0IGFsbCBmbGFncyBTL1NBIGtl ZXAgc3RhdGUKCm5hdCBvbiB1ZTAgaW5ldCBmcm9tIDEwLjAuMC4yIHRvIGFueSAtPiAodWUw KSByb3VuZC1yb2JpbgpyZHIgb24gdWUwIGluZXQgcHJvdG8gdWRwIGZyb20gYW55IHRvICh1 ZTApIHBvcnQgPSBycGxheSAtPiAxMC4wLjAuMgoKdWUwOiBmbGFncz04ODQzPFVQLEJST0FE Q0FTVCxSVU5OSU5HLFNJTVBMRVgsTVVMVElDQVNUPiBtZXRyaWMgMCBtdHUgMTUwMAogICAg ICAgIG9wdGlvbnM9ODAwMDk8UlhDU1VNLFZMQU5fTVRVLExJTktTVEFURT4KICAgICAgICBl dGhlciBiODoyNzplYjo1NTo3ZTo3MAogICAgICAgIGluZXQgMTkyLjE2OC4xNzguMyBuZXRt YXNrIDB4ZmZmZmZmMDAgYnJvYWRjYXN0IDE5Mi4xNjguMTc4LjI1NQogICAgICAgIG1lZGlh OiBFdGhlcm5ldCBhdXRvc2VsZWN0ICgxMDBiYXNlVFggPGZ1bGwtZHVwbGV4PikKICAgICAg ICBzdGF0dXM6IGFjdGl2ZQogICAgICAgIG5kNiBvcHRpb25zPTI5PFBFUkZPUk1OVUQsSUZE SVNBQkxFRCxBVVRPX0xJTktMT0NBTD4KCkZyZWVCU0QgMTMuMC1DVVJSRU5UICMxIHIzNjc3 MTRNOiBNb24gTm92IDE2IDA4OjAzOjI0IFVUQyAyMDIwICAgICByb290QHN5c2J1aWxkOi91 c3Ivb2JqL3Vzci9zcmNfaGVhZC9hcm02NC5hYXJjaDY0L3N5cy9HRU5FUklDCgotLS0Kcm9v dEB0ZXN0LWFtZDY0On4gIyBucGluZyAtYyAxIC0tdWRwIC1wIDU1NTUgMTkyLjE2OC4xNzgu MwoKU3RhcnRpbmcgTnBpbmcgMC43LjgwICggaHR0cHM6Ly9ubWFwLm9yZy9ucGluZyApIGF0 IDIwMjAtMTEtMTggMDk6MzQgQ0VUClNFTlQgKDAuMDA0OHMpIFVEUCAxOTIuMTY4LjE3OC4y OTo1MyA+IDE5Mi4xNjguMTc4LjM6NTU1NSB0dGw9NjQgaWQ9ODUzIGlwbGVuPTI4ClJDVkQg KDAuMDA1OHMpIElDTVAgWzE5Mi4xNjguMTc4LjMgPiAxOTIuMTY4LjE3OC4yOSBQb3J0IHVu cmVhY2hhYmxlICh0eXBlPTMvY29kZT0zKSBdIElQIFt0dGw9NjQgaWQ9NTYyMzYgaXBsZW49 NTYgXQoKTWF4IHJ0dDogMC44MTRtcyB8IE1pbiBydHQ6IDAuODE0bXMgfCBBdmcgcnR0OiAw LjgxNG1zClJhdyBwYWNrZXRzIHNlbnQ6IDEgKDI4QikgfCBSY3ZkOiAxICg1NkIpIHwgTG9z dDogMCAoMC4wMCUpCk5waW5nIGRvbmU6IDEgSVAgYWRkcmVzcyBwaW5nZWQgaW4gMS4wNCBz ZWNvbmRzCgotLS0Kcm9vdEB0ZXN0LWFtZDY0On4gIyBucGluZyAtYyAxIC0tdWRwIC1wIDU1 NTUgLS1kYXRhLWxlbmd0aCAxMDAgMTkyLjE2OC4xNzguMwoKU3RhcnRpbmcgTnBpbmcgMC43 LjgwICggaHR0cHM6Ly9ubWFwLm9yZy9ucGluZyApIGF0IDIwMjAtMTEtMTggMDk6MzUgQ0VU ClNFTlQgKDAuMDA0N3MpIFVEUCAxOTIuMTY4LjE3OC4yOTo1MyA+IDE5Mi4xNjguMTc4LjM6 NTU1NSB0dGw9NjQgaWQ9MjE1ODUgaXBsZW49MTI4CgpNYXggcnR0OiBOL0EgfCBNaW4gcnR0 OiBOL0EgfCBBdmcgcnR0OiBOL0EKUmF3IHBhY2tldHMgc2VudDogMSAoMTI4QikgfCBSY3Zk OiAwICgwQikgfCBMb3N0OiAxICgxMDAuMDAlKQpOcGluZyBkb25lOiAxIElQIGFkZHJlc3Mg cGluZ2VkIGluIDEuMDEgc2Vjb25kcwo= --------------6D413B37D402893C04AB9EB3 Content-Type: text/plain; charset=UTF-8; name="nping_rxcsum_off_pf_jail.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="nping_rxcsum_off_pf_jail.txt" cm9vdEBnZW5lcmljOn4gIyBwZmN0bCAtc3IgOyBlY2hvIDsgcGZjdGwgLXNuIDsgZWNobyA7 IGlmY29uZmlnIHVlMCA7IGVjaG8gOyB1bmFtZSAtdgpibG9jayByZXR1cm4gaW4gYWxsCnBh c3MgaW4gaW5ldCBwcm90byBpY21wIGFsbCBpY21wLXR5cGUgZWNob3JlcSBrZWVwIHN0YXRl CnBhc3MgaW4gaW5ldCBwcm90byB0Y3AgZnJvbSBhbnkgdG8gYW55IHBvcnQgPSBzc2ggZmxh Z3MgUy9TQSBrZWVwIHN0YXRlCnBhc3MgaW4gaW5ldCBwcm90byB1ZHAgZnJvbSBhbnkgdG8g YW55IHBvcnQgPSBycGxheSBrZWVwIHN0YXRlCnBhc3Mgb3V0IGFsbCBmbGFncyBTL1NBIGtl ZXAgc3RhdGUKCm5hdCBvbiB1ZTAgaW5ldCBmcm9tIDEwLjAuMC4yIHRvIGFueSAtPiAodWUw KSByb3VuZC1yb2JpbgpyZHIgb24gdWUwIGluZXQgcHJvdG8gdWRwIGZyb20gYW55IHRvICh1 ZTApIHBvcnQgPSBycGxheSAtPiAxMC4wLjAuMgoKdWUwOiBmbGFncz04ODQzPFVQLEJST0FE Q0FTVCxSVU5OSU5HLFNJTVBMRVgsTVVMVElDQVNUPiBtZXRyaWMgMCBtdHUgMTUwMAogICAg ICAgIG9wdGlvbnM9ODAwMDg8VkxBTl9NVFUsTElOS1NUQVRFPgogICAgICAgIGV0aGVyIGI4 OjI3OmViOjU1OjdlOjcwCiAgICAgICAgaW5ldCAxOTIuMTY4LjE3OC4zIG5ldG1hc2sgMHhm ZmZmZmYwMCBicm9hZGNhc3QgMTkyLjE2OC4xNzguMjU1CiAgICAgICAgbWVkaWE6IEV0aGVy bmV0IGF1dG9zZWxlY3QgKDEwMGJhc2VUWCA8ZnVsbC1kdXBsZXg+KQogICAgICAgIHN0YXR1 czogYWN0aXZlCiAgICAgICAgbmQ2IG9wdGlvbnM9Mjk8UEVSRk9STU5VRCxJRkRJU0FCTEVE LEFVVE9fTElOS0xPQ0FMPgoKRnJlZUJTRCAxMy4wLUNVUlJFTlQgIzEgcjM2NzcxNE06IE1v biBOb3YgMTYgMDg6MDM6MjQgVVRDIDIwMjAgICAgIHJvb3RAc3lzYnVpbGQ6L3Vzci9vYmov dXNyL3NyY19oZWFkL2FybTY0LmFhcmNoNjQvc3lzL0dFTkVSSUMKCi0tLQpyb290QHRlc3Qt YW1kNjQ6fiAjIG5waW5nIC1jIDEgLS11ZHAgLXAgNTU1NSAxOTIuMTY4LjE3OC4zCgpTdGFy dGluZyBOcGluZyAwLjcuODAgKCBodHRwczovL25tYXAub3JnL25waW5nICkgYXQgMjAyMC0x MS0xOCAxMDoyNyBDRVQKU0VOVCAoMC4wMDQ4cykgVURQIDE5Mi4xNjguMTc4LjI5OjUzID4g MTkyLjE2OC4xNzguMzo1NTU1IHR0bD02NCBpZD01NDcwNSBpcGxlbj0yOApSQ1ZEICgwLjAw NTdzKSBJQ01QIFsxOTIuMTY4LjE3OC4zID4gMTkyLjE2OC4xNzguMjkgUG9ydCB1bnJlYWNo YWJsZSAodHlwZT0zL2NvZGU9MykgXSBJUCBbdHRsPTY0IGlkPTE2MDEzIGlwbGVuPTU2IF0K Ck1heCBydHQ6IDAuNzg4bXMgfCBNaW4gcnR0OiAwLjc4OG1zIHwgQXZnIHJ0dDogMC43ODht cwpSYXcgcGFja2V0cyBzZW50OiAxICgyOEIpIHwgUmN2ZDogMSAoNTZCKSB8IExvc3Q6IDAg KDAuMDAlKQpOcGluZyBkb25lOiAxIElQIGFkZHJlc3MgcGluZ2VkIGluIDEuMDQgc2Vjb25k cwoKLS0tCnJvb3RAdGVzdC1hbWQ2NDp+ICMgbnBpbmcgLWMgMSAtLXVkcCAtcCA1NTU1IC0t ZGF0YS1sZW5ndGggMTAwIDE5Mi4xNjguMTc4LjMKClN0YXJ0aW5nIE5waW5nIDAuNy44MCAo IGh0dHBzOi8vbm1hcC5vcmcvbnBpbmcgKSBhdCAyMDIwLTExLTE4IDEwOjI4IENFVApTRU5U ICgwLjAwNDlzKSBVRFAgMTkyLjE2OC4xNzguMjk6NTMgPiAxOTIuMTY4LjE3OC4zOjU1NTUg dHRsPTY0IGlkPTYxMjk5IGlwbGVuPTEyOApSQ1ZEICgwLjAwNTlzKSBJQ01QIFsxOTIuMTY4 LjE3OC4zID4gMTkyLjE2OC4xNzguMjkgUG9ydCA1NTU1IHVucmVhY2hhYmxlICh0eXBlPTMv Y29kZT0zKSBdIElQIFt0dGw9NjQgaWQ9MjU0NTIgaXBsZW49MTU2IF0KCk1heCBydHQ6IDAu OTE5bXMgfCBNaW4gcnR0OiAwLjkxOW1zIHwgQXZnIHJ0dDogMC45MTltcwpSYXcgcGFja2V0 cyBzZW50OiAxICgxMjhCKSB8IFJjdmQ6IDEgKDE1NkIpIHwgTG9zdDogMCAoMC4wMCUpCk5w aW5nIGRvbmU6IDEgSVAgYWRkcmVzcyBwaW5nZWQgaW4gMS4wNyBzZWNvbmRzCg== --------------6D413B37D402893C04AB9EB3-- From owner-freebsd-hackers@freebsd.org Wed Nov 18 10:23:11 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3FF1D2EA1E1 for ; Wed, 18 Nov 2020 10:23:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Cbf5n4g1dz3D5d for ; Wed, 18 Nov 2020 10:23:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 0AIAMwl5018126 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 18 Nov 2020 12:23:01 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 0AIAMwl5018126 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 0AIAMwn9018125; Wed, 18 Nov 2020 12:22:58 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 18 Nov 2020 12:22:58 +0200 From: Konstantin Belousov To: Norbert Koch Cc: freebsd-hackers@freebsd.org Subject: Re: pci function level reset Message-ID: References: <8a8c7813-18fc-6dd3-28b3-803e48f89131@demig.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8a8c7813-18fc-6dd3-28b3-803e48f89131@demig.de> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 4Cbf5n4g1dz3D5d X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [-1.00 / 15.00]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2001:470:d5e7:1::1:from]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_SPF_SOFTFAIL(0.00)[~all:c]; NEURAL_SPAM_SHORT(1.00)[1.000]; SPAMHAUS_ZRD(0.00)[2001:470:d5e7:1::1:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MIME_TRACE(0.00)[0:+]; MAILMAN_DEST(0.00)[freebsd-hackers]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2020 10:23:11 -0000 On Wed, Nov 18, 2020 at 10:27:19AM +0100, Norbert Koch wrote: > Hello. > > I am running 12.1 on an embedded board which is equipped with an > intel gbit ethernet controller (Intel PRO/1000, em driver). > > Either the ethernet controller or the bios has a bug, which > the board manufacturer confirmed. > > After soft reboot gbit ethernet sometimes stops working > while 100/10mbit are ok. > Only after power down gbit works again (mostly). > > As they only support windows and linux, their "fix" is writing > a '1' to /sys/bus/pci/devices/$dev/reset. > They say this is a "function level reset", whatever this means. > > Is there any way (e.g. using pciconf) to do this under FreeBSD? devctl reset pci::: where d:b:s:f is the pci address of your device. If device supports FLR, it should do exactly that. From owner-freebsd-hackers@freebsd.org Wed Nov 18 21:46:10 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1C767472DD9; Wed, 18 Nov 2020 21:46:10 +0000 (UTC) (envelope-from vmaffione@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CbxFt0Gc0z4hrg; Wed, 18 Nov 2020 21:46:10 +0000 (UTC) (envelope-from vmaffione@freebsd.org) Received: from mail-pf1-f177.google.com (mail-pf1-f177.google.com [209.85.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: vmaffione) by smtp.freebsd.org (Postfix) with ESMTPSA id EA9DF2C9A5; Wed, 18 Nov 2020 21:46:09 +0000 (UTC) (envelope-from vmaffione@freebsd.org) Received: by mail-pf1-f177.google.com with SMTP id a18so2413021pfl.3; Wed, 18 Nov 2020 13:46:09 -0800 (PST) X-Gm-Message-State: AOAM532GSNJZo0efBBU41tldn3rvVA075bcigFQPiHamd/JqC4x/eTwD If+gojiP2SzFDpDKJ0lHVVopfybc2Uf21he94+U= X-Google-Smtp-Source: ABdhPJwd5LIx8MTO2po4EDgctCDYy5Tp8Keb4XL9jqsR9Z4TT6BcWak7AbyNskdpICc9+ezpsY5cMhPHoRrfhRURKU8= X-Received: by 2002:a17:90a:e016:: with SMTP id u22mr1087315pjy.54.1605735968876; Wed, 18 Nov 2020 13:46:08 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Vincenzo Maffione Date: Wed, 18 Nov 2020 22:45:57 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Netmap bridge not working with 10G Ethernet ports To: Rajesh Kumar Cc: "freebsd-net@freebsd.org" , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2020 21:46:10 -0000 Hi, Il giorno mer 18 nov 2020 alle ore 08:13 Rajesh Kumar ha scritto: > Hi, > > I am testing a 10G Network driver with Netmap "bridge" utility, where it > doesn't seem to work. Here is my setup details. > > *System under Test:* Running FreeBSD CURRENT. Has two inbuilt 10G NIC > ports. > *System 1:* Running Ubuntu, whose network port is connected to Port1 of > System Under Test > *System 2:* Running FreeBSD CURRENT, whose network port is connected to > Port 0 of System Under Test. > > Bridged the Port0 and Port1 of System Under Test using the Netmap "bridge" > utility. Able to see interfaces coming up active and Link UP. > # bridge -c -v -i netmap:ax0 -i netmap:ax1 > > This looks like if_axe(4) driver, and therefore there's no native netmap support, which means you are falling back on the emulated netmap adapter. Are these USB dongles? If so, how can they be 10G? > Then tried pinging from System 1 to System 2. It fails. > > *Observations:* > 1. ARP request from System 1 goes to bridge port 1 (netmap_rxsync) and then > forwarded to port 0 (netmap_txsync) > 2. ARP request is received in System 2 (via bridge port 0) and ARP reply is > being sent from System 2. > 3. ARP reply from System 2 seems to be not reaching bridge port 0 to get > forwarded to bridge 1 and hence to System 1. > 4. Above 3 steps happen 3 times for ARP resolution cycle and then fails. > Hence the ping fails. > > On Debugging, when the ARP reply is being sent from System 2, I don't see > any interrupt triggered on the bridge port 0 in system under test. > > In this kind of configuration it is mandatory to disable all the NIC offloads, because netmap does not program the NIC to honor them, e.g.: # ifconfig ax0 -txcsum -rxcsum -tso4 -tso6 -lro -txcsum6 -rxcsum6 # ifconfig ax1 -txcsum -rxcsum -tso4 -tso6 -lro -txcsum6 -rxcsum6 > Netstat in system under test, doesn't show any receive or drop counters > incremented. But as I understand netstat capture the stats above the netmap > stack. Hence not reflecting the counts. > Correct. > > *Note:* > a) I tried with another vendor 10G NIC card. It behaves the same way. So > this issue doesn't seem to be generic and not hardware specific. > Which driver are those NICs using? That makes the difference. I guess it's still a driver with no native netmap support, hence you are using the same emulated adapter. > b) Trying with another vendor 1G NIC card, things are working. So not > sure, what makes a difference here. The ports in System 1 and System 2 are > USB attached Ethernet capable of maximum speed of 1G. So does connecting > 1G to 10G bridge ports is having any impact? > I don't think so. On each p2p link the NICs will negotiate 1G speed. In any case, what driver was this one? > c) We have verified the same 10G driver with pkt-gen utility and things are > working. Facing issue only when using "bridge" utility. > That may be because pkt-gen does not care about checksums, whereas the TCP/IP stack does. Hence the need to disable offloads (see above). Cheers, Vincenzo > So, wondering how the ARP reply packet is getting lost here. Any ideas to > debug? > > Thanks, > Rajesh. > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Thu Nov 19 02:22:12 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5BFD447BC7C; Thu, 19 Nov 2020 02:22:12 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Cc3NN1v8Xz3JqC; Thu, 19 Nov 2020 02:22:11 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by mail-pg1-x529.google.com with SMTP id 62so2800451pgg.12; Wed, 18 Nov 2020 18:22:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=NK7k7lpxMllAWLL0yEzY4uJiczYqC+bj/iG9k0Sgn/Q=; b=r61MU/uGKPtpb0ROTVMSAdiCcukHJ4ZgDftMW9T2hD5/dF9Zd8CZVZR/Z4YZIHNuLI cK5R/r2jx5uKLlYv8TRE2YMDgMJlaGClDSi5AhCiM51dtKPTPppnUj/1iVPr4zk70ad2 LNvAv1W0B3e3GXCxkjMZX+1F5TKteP7IhmquMdTi7G4vHWSNngN8r/XrVmYTBNNt79n9 oDo2TgohEJp7CG8jrSgdp5SbroG+U195wAzi6QK1eZ6d6USkxRmI8a/bR8wpRiOPhCZR +sSIzpMBt+0974Uu0/b6ezooWJzlVvyYsiYk7iv5Ax+21bA8xbyVqpLR71X3GMm/TZ2e NDzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=NK7k7lpxMllAWLL0yEzY4uJiczYqC+bj/iG9k0Sgn/Q=; b=LD9ZLywlOFWSv+FG6sPiN6+gbtAdZUlNdALsIhmRvtFc3ycezgEytEhCG/KTs2BM0x JqBpN2qiZkT9Jz8i1NuwpkHi1OgA81Wht3J09nNGOZDt6qSjM8C/GVo5kyiOOAE/mh+G Kp1525TgU+9OX2P3tBIXwl3yGulQr0NB17/tHw37qcCsmd5gUS/C5zO3BykX/8Ajg22J Vri4xAMsVyAeeuvmFySIHt0HX9/1pV3xWrU3lTNLqx7nfNPrYrLb/AuDmJ0YH1YSDyRz wKYruAgX5GOD2Ad+nhu4/Jj9+1+AWwncIDxBlEgoclDmUNqXnumpJbNbXSMM3s3wpC4Z fb+w== X-Gm-Message-State: AOAM5304lGuB7040AMwE1/fLfI88nAP6k8OXNe3D7ANw8AOwx2uqlaaS IoBBeaCAokHwkTOfBBN08CM= X-Google-Smtp-Source: ABdhPJzZc+zrM4UJbWcRsLaTZLFRm3sVCa6hIKTtmP1/ML4aZBfWzjRAq4ZpduLVMjbrOiOgCP5o1g== X-Received: by 2002:a17:90a:bc83:: with SMTP id x3mr1973141pjr.90.1605752530775; Wed, 18 Nov 2020 18:22:10 -0800 (PST) Received: from localhost ([210.108.244.139]) by smtp.gmail.com with ESMTPSA id w66sm30840522pff.171.2020.11.18.18.22.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Nov 2020 18:22:10 -0800 (PST) Date: Thu, 19 Nov 2020 11:22:08 +0900 From: YongHyeon PYUN To: Carsten =?iso-8859-1?Q?B=E4cker?= Cc: Hans Petter Selasky , Kristof Provost , freebsd-arm@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Problem with checksum offloading on RPi3 (PF + Jails involved) Message-ID: <20201119022208.GB1974@michelle> References: <20201103045215.GA2524@michelle> <46d08198-530c-cb4b-efa8-4edaf89471c1@selasky.org> <4dfaa9a3-c085-8466-a6e4-19f988b5ed3d@selasky.org> <20201116011910.GB1941@michelle> <1245cbe5-9d2f-4808-f989-569ae7d57a8a@gmx.de> <20201117030406.GA45158@michelle> <20201118044857.GA1974@michelle> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 4Cc3NN1v8Xz3JqC X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 02:22:12 -0000 On Wed, Nov 18, 2020 at 10:47:08AM +0100, Carsten Bäcker wrote: [...] > Sorry, that's my fault - i overlooked your request for a test with pf > enabled. > The example-ruleset is attached again. I added a line to allow the > incoming ping to 5555. > > I don't see a difference until i enable the redirection to the jail > which makes the packet with extended data-length fail. > Once i disable RXCSUM it works. > Thanks for testing. Unfortunately I couldn't find a driver issue on patched smsc(4). Quick looking pf(4) makes me wonder how it verifies UDP datagrams. Kristof, does pf(4) take advantage of H/W checksummed result for UDP datagrams? It seems pf_check_proto_cksum() always pass IPPROTO_TCP such that UDP pseudo checksum is not computed in the function. I'm under the impression that incremental checksum update for UDP datagrams with only CSUM_DATA_VALID bit wouldn't work. From owner-freebsd-hackers@freebsd.org Thu Nov 19 02:53:16 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BCAEF47CEC9 for ; Thu, 19 Nov 2020 02:53:16 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "m5p.com", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Cc44C5rpLz3Lfv for ; Thu, 19 Nov 2020 02:53:12 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from [IPv6:2001:470:1f07:15ff::26] (court.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:26]) (authenticated bits=0) by mailhost.m5p.com (8.15.2/8.15.2) with ESMTPSA id 0AJ2qxA7007498 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Wed, 18 Nov 2020 21:53:05 -0500 (EST) (envelope-from george+freebsd@m5p.com) To: FreeBSD Hackers From: George Mitchell Subject: How is Thunderbird signing my emails? Message-ID: <9e617638-0bd9-52cd-c361-8d73633d9bab@m5p.com> Date: Wed, 18 Nov 2020 21:52:59 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3ftFdB9rayFRKjgf4o4d6ZMELTKeaDRcO" X-Spam-Status: No, score=0.0 required=10.0 tests=HELO_MISC_IP,HELO_NO_DOMAIN autolearn=unavailable autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mattapan.m5p.com X-Rspamd-Queue-Id: 4Cc44C5rpLz3Lfv X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of george@m5p.com designates 74.104.188.4 as permitted sender) smtp.mailfrom=george@m5p.com X-Spamd-Result: default: False [-4.40 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; HAS_ATTACHMENT(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; R_DKIM_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[74.104.188.4:from]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; TAGGED_FROM(0.00)[freebsd]; ASN(0.00)[asn:701, ipnet:74.104.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[m5p.com]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[74.104.188.4:from:127.0.2.255]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 02:53:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3ftFdB9rayFRKjgf4o4d6ZMELTKeaDRcO Content-Type: multipart/mixed; boundary="MtOUwwpgRRiknArmACQ6MjM4z6UWudVBT"; protected-headers="v1" From: George Mitchell To: FreeBSD Hackers Message-ID: <9e617638-0bd9-52cd-c361-8d73633d9bab@m5p.com> Subject: How is Thunderbird signing my emails? --MtOUwwpgRRiknArmACQ6MjM4z6UWudVBT Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable The Thunderbird people have integrated the functionality of Enigmail into Thunderbird itself. In the abstract, this sounds like a great idea, because I believe that the more people use PGP signatures and encryption, the better. But the concrete reality of the implementation puzzles me in a couple of respects: a. It's now inclined to attach my public key to every message I send, unless I tell it it not to do that on a message-by-message basis (under the "Security" menu in the message composition dialog). I can't find where I can globally disable this. b. More alarmingly, when it appends my PGP signature to my outgoing messages, it is able to unlock my private key without asking for the passphrase. How is it doing this?? Enigmail (not unexpectedly) always had to ask for my passphrase, unless I had supplied it in the last five minutes. -- George --MtOUwwpgRRiknArmACQ6MjM4z6UWudVBT-- --3ftFdB9rayFRKjgf4o4d6ZMELTKeaDRcO Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEENdM4ZHktsJW5kKZXwRES3m+p4fkFAl+13gsFAwAAAAAACgkQwRES3m+p4fm2 HQ//TggauxQ7Bf66wgLOOyH0YLQXriJfPK0WSbYAvayZNTQ60xUdor4d86isa3d4KK372SjfwdBM CJLnpL2ahdPmR+oC4XhYCVRQjrcpALYSnI9/JR89yZCak4bTPy6aFIYl1QdUbPjc07KCq7klHYKm tnmSHt89uuX4BvyAYk/nCSBzCcjDryfDNc2ZiAb4POPF38Xe8p2bR8tYExqEL06S6uYXD9abFeuf AQ3j2iAoWFeX4Ta90Im1LQW0CGLfc97R9FUWe0aMx3nfGf7Ety70x+ECyLpE6y9KKCmLtCVWmSqP M9Mb1BApn1o0bChlwbFOFpIm0A33rR4BGFwUOgeK50EivenYLug00gR3wWHnqfifSS3nGIBli30G 0UYBpkqITidDWHHjdJtewrDeXBnfwuREQfmXo17vWjGZdMEPyQj1OCT39bvVvLktmGLSI49fDyb4 ClGNrxPRfz4Dt/AfdZn5PaGVduEUihbhTKh+uTi1zPTDAGB4cV/aDkWrYS/S+5+qLYvJKrt6vw/v lxUEx0ErZ6ZEiL51/9/IsSZj+d3wgNG39tlqZfqiNR19MWuswoGDQsW+roQRgSgHjyQrjUc4LBXW YUxWe/DpFJ5u0zz6Z+NbvdRoJpjw6MkUwr+4I4jeEoNDA7tJxYRvqrwQ74JktSrDwGxCwtQEiDIb TFk= =+TWY -----END PGP SIGNATURE----- --3ftFdB9rayFRKjgf4o4d6ZMELTKeaDRcO-- From owner-freebsd-hackers@freebsd.org Thu Nov 19 07:35:59 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8787F2EA600; Thu, 19 Nov 2020 07:35:59 +0000 (UTC) (envelope-from carbaecker@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CcBLR1jQtz3qn6; Thu, 19 Nov 2020 07:35:58 +0000 (UTC) (envelope-from carbaecker@gmx.de) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1605771356; bh=HWHo/zULhroyb7+GDbAyEjCh99L8kaH+c9JdRk/3r8Q=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=hp5UjPXsHRYppJQsgyA19mHsuMhTy3bmmDgEMguqW13Gp5uw10nK5zbUT338TVLnN L2fx9kknM0N1WnxxlsDYiJe3bqDzHOkp/qCpGz8j+o2eQzpROoh3zarkNHWiKVxEx3 M6mxBvv0sSx1tkbTkvZWPESNdhewh/H9np+kboJc= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.30] ([94.31.96.148]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MK3W0-1kxst00Reo-00LRqI; Thu, 19 Nov 2020 08:35:56 +0100 Subject: Re: Problem with checksum offloading on RPi3 (PF + Jails involved) To: YongHyeon PYUN Cc: Hans Petter Selasky , Kristof Provost , freebsd-arm@freebsd.org, freebsd-hackers@freebsd.org References: <20201103045215.GA2524@michelle> <46d08198-530c-cb4b-efa8-4edaf89471c1@selasky.org> <4dfaa9a3-c085-8466-a6e4-19f988b5ed3d@selasky.org> <20201116011910.GB1941@michelle> <1245cbe5-9d2f-4808-f989-569ae7d57a8a@gmx.de> <20201117030406.GA45158@michelle> <20201118044857.GA1974@michelle> <20201119022208.GB1974@michelle> From: =?UTF-8?Q?Carsten_B=c3=a4cker?= Message-ID: <117fea06-11ed-c074-1880-bef75c57d662@gmx.de> Date: Thu, 19 Nov 2020 08:35:54 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: <20201119022208.GB1974@michelle> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: de-DE X-Provags-ID: V03:K1:NFDasVzA0U8ax2dg/BClZScYjcyZJm2bAr/QE7YCvIM/yUl12dB +mKZl4IY2Oo+v9spsDcrTsZRLhRMGc2e7+TRPWu1a8HptvwtatXZ8KBAcX+vkuM/r62g3xB EQRJRY8CP9TGov168YVaEp9E42u5IcbnFcYN5BIre73Pq6S+lCPZgKyfg7zDlcjcfW2UjxL IBeIuOiAwRjU2UYum8K+g== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:lXnAKqUO49I=:CUYMjphv08DxB1NBjpbZK7 kbJvVnnPbIE9m83c9Z6ySYam4y0ZX13zkE0/VgIAY7QPRex9dHoTIdr9jsUg6v+e114d0qaC9 WFawlMtRw6A2J7k4nxcXwvuZ8Ej9xu5xCHwSDMGKmXOWkXyiumpKlajY+d3NCU9qoF3i5E5hm cPomKHjYCiTCf9V2Y70F/drtS0IGZVrjZmqam0hs4gBnkemMRJAkwcwOVMnIgZnBtGaeI31dL 7TxO6eFdaoMzrJzvr+Bl1yD7CTqbyqLUABpBCSBfy44FKR79N6Smhm2upoV+w3tHzjOPd1P2X 174nx0s3MrRKxmwFR/qeT+VUecQvFoenYS8NyxprRDsHxQeDj4VZ7cVNITUoYgeDrNceC4AsI 0xDCbGCi7ERxxcqcYtpQhRHsOQyPt9pH7pTRO4nShbqcehUyvJ9VBF4GCLEKpHasT+Pmpu06I tFA9Uz7Qpwag2qskSyIcZLi/OKdWVlmQt6GcmFVKORsMbT98eqRQUmCMqhbbgGN+IAMS7h/ES NXhdzwAnWIRUusNEFIz/kDpdEmoINH/9R0DvDR9f6YxLyIqDlcUu1OFWYYO4ooxeidpK9EzEv N8YZUC9Svs0gRyCA9rJCWaRuvTxv0FNVvcXrzJlwwrA/b5On8Hh02qMKpdBR6aPMjFC5m5oDV JKFWmImLwat0MYzFXelGulUVFEgB9PiKY0/bFVSnV3pGJej8FHM26PG6qmYhNLt5Z5iky2UMb GosLCPe2USHDF2ttTFaEK7+KjLP8icR80hIV7SyrCVG9KgwmlAodWDdDc2n8Zg+n1k10SLHvX MFgA/qY1HDzRxmuyW+8L2iskAWq6uztzc5qAP2ZUh5XveOleFhBQJZ2Nk/QrpsZRo54b8tvy+ PTVv7Rf7ygy2YzeHpStQ== X-Rspamd-Queue-Id: 4CcBLR1jQtz3qn6 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 07:35:59 -0000 Am 19.11.2020 um 03:22 schrieb YongHyeon PYUN: > On Wed, Nov 18, 2020 at 10:47:08AM +0100, Carsten B=C3=A4cker wrote: > > [...] > >> Sorry, that's my fault - i overlooked your request for a test with pf >> enabled. >> The example-ruleset is attached again. I added a line to allow the >> incoming ping to 5555. >> >> I don't see a difference until i enable the redirection to the jail >> which makes the packet with extended data-length fail. >> Once i disable RXCSUM it works. >> > Thanks for testing. Unfortunately I couldn't find a driver issue > on patched smsc(4). Quick looking pf(4) makes me wonder how it > verifies UDP datagrams. > > Kristof, does pf(4) take advantage of H/W checksummed result for > UDP datagrams? It seems pf_check_proto_cksum() always pass > IPPROTO_TCP such that UDP pseudo checksum is not computed in the > function. I'm under the impression that incremental checksum > update for UDP datagrams with only CSUM_DATA_VALID bit wouldn't > work. Just did a quick test with the RPI4, using the sd-card from the previous run. The lengthly packet fails even with pf disabled. Surprisingly the original problem (within the NAT-ted jail) disappeared. From owner-freebsd-hackers@freebsd.org Thu Nov 19 11:01:39 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BFF362EF731 for ; Thu, 19 Nov 2020 11:01:39 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CcGvl58h4z4XDy for ; Thu, 19 Nov 2020 11:01:39 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.not-for.work (onlyone.not-for.work [148.251.9.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: lev/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 8B9032C37 for ; Thu, 19 Nov 2020 11:01:39 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [192.168.23.230] (unknown [89.113.128.32]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id C1A982C3C for ; Thu, 19 Nov 2020 14:01:36 +0300 (MSK) Reply-To: lev@FreeBSD.org Subject: Re: How is Thunderbird signing my emails? To: freebsd-hackers@freebsd.org References: <9e617638-0bd9-52cd-c361-8d73633d9bab@m5p.com> From: Lev Serebryakov Organization: FreeBSD Message-ID: <3e4179d0-f6c4-66a5-9628-b2ee95071858@FreeBSD.org> Date: Thu, 19 Nov 2020 14:01:36 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: <9e617638-0bd9-52cd-c361-8d73633d9bab@m5p.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 11:01:39 -0000 On 19.11.2020 5:52, George Mitchell wrote: > The Thunderbird people have integrated the functionality of Enigmail > into Thunderbird itself.  In the abstract, this sounds like a great > idea, because I believe that the more people use PGP signatures and > encryption, the better.  But the concrete reality of the implementation > puzzles me in a couple of respects: Concrete reality of the implementation is awful. It is not replacement for Enigmail :-( > > a. It's now inclined to attach my public key to every message I send, > unless I tell it it not to do that on a message-by-message basis (under > the "Security" menu in the message composition dialog).  I can't find > where I can globally disable this. See https://bugzilla.mozilla.org/show_bug.cgi?id=1654950 - new releases will have hidden setting for it. > b. More alarmingly, when it appends my PGP signature to my outgoing > messages, it is able to unlock my private key without asking for the > passphrase.  How is it doing this?? New Thunderbird doesn't use GPG keyring, it imports all keys into its own database (also it doesn't use Web Of Trust!). Private keys are protected only by global profile password (did you have this one set? I'm in doubt, it is rarely-used feature). So, if you account is without global password, you imported private keys are not protected at all. Good luck with that :-( -- // Lev Serebryakov From owner-freebsd-hackers@freebsd.org Thu Nov 19 11:28:56 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 85A9E2EFFB1; Thu, 19 Nov 2020 11:28:56 +0000 (UTC) (envelope-from rajfbsd@gmail.com) Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CcHWD3Bk7z4YBV; Thu, 19 Nov 2020 11:28:56 +0000 (UTC) (envelope-from rajfbsd@gmail.com) Received: by mail-ot1-x334.google.com with SMTP id n89so4944999otn.3; Thu, 19 Nov 2020 03:28:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mdN8Uo/HeiG8juRtBFCcYjEG+o6U53xrDKKFwZvI9T0=; b=uua+E2PKC6+RGSRusA9CHyGAfEzYh0Av6dRl5CwhN3KHgESf01b16A2FLeV19RTUH8 une2eyVgA79x6Gg9rEzgi2XKv9VZgCLTB2FexnqyxrIJmH6fH9aoXqsXeuuWFsOaeXi0 Pky7MSdTBbjwgNiW+aF94sPJB+GkldrrlvllmOga+0Ne1iM+RdbKIKaZUpM+sVnXAzeS e04fexwrqVFhCLqbJYqPRxQzoKY7+uLzRUYk0Db9rSB5vmJec1hcpSR/9fEepxuV7Uci rPZ7cWIWNW580am+in9FKAtLugOBVamEdqqs8RmElvYNdoJy/QVFnkf0mENqNxQbWKQu moCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mdN8Uo/HeiG8juRtBFCcYjEG+o6U53xrDKKFwZvI9T0=; b=FJ56MakSDefmIY1I8nnQoQVpxPyiafHr5whLOYA7kfUaToHqotDYwmViaHMJTWoge7 sLCjp8As2AJFs5dhWeiUBOg0UkDgxRQwHVWCiVUDO344EKYaD4vA+dslbuerYufyPDfx 2CNYecDkD0lCc4ga+vg39QFZNK7Ou1Tw4t9esJoDBQpQpCQ7flr40XKYE9g6bjgRTqYH PgfARbdM7RXJaZQxRmBY9LnYgFjpr7qSQm/J6DsV3tYcvlUaX1QXjBgT5KHChy8j5/fK dr9SwtLfiUVQpUp3JKQHrhLlDaqLBoYSoN/paVxsm6AzUnLi1wjesXUh/B0dHrnDckz9 +Rrg== X-Gm-Message-State: AOAM530hxO1wieBKapU0q/+l2f+danQU6w8mC7QeYkqM3QBy+TmlLxdH L0J0XiTvTaxD2V0pi/QRUgA53r747Ga79dj9owcAdKzP1x8= X-Google-Smtp-Source: ABdhPJwavgMaWO4FJQyrT+L7nx8QmJ1QVCwQa70LGnucvWntFrdFK91+Y5X5Zq3phHPAJ5B7TKmXCLuWcBy8M3NHu4g= X-Received: by 2002:a9d:76d7:: with SMTP id p23mr9967605otl.180.1605785334727; Thu, 19 Nov 2020 03:28:54 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Rajesh Kumar Date: Thu, 19 Nov 2020 16:58:42 +0530 Message-ID: Subject: Re: Netmap bridge not working with 10G Ethernet ports To: Vincenzo Maffione Cc: "freebsd-net@freebsd.org" , FreeBSD Hackers X-Rspamd-Queue-Id: 4CcHWD3Bk7z4YBV X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 11:28:56 -0000 Hi Vincenzo, Thanks for your reply. On Thu, Nov 19, 2020 at 3:16 AM Vincenzo Maffione wrote: > > This looks like if_axe(4) driver, and therefore there's no native netmap > support, which means you are falling back on > the emulated netmap adapter. Are these USB dongles? If so, how can they be > 10G? > The Driver I am working with is "if_axp" (sys/dev/axgbe). This is AMD 10Gigabit Ethernet Driver. This is recently committed upstream. Yes, it doesn't have a Native netmap support, but uses the netmap stack which is existing already. These are inbuilt SFP ports with our test board and not USB dongles. Does Native netmap mean the hardware capability which needs to be programmed appropriately from driver side? Any generic documentation regarding the same? > In this kind of configuration it is mandatory to disable all the NIC > offloads, because netmap does not program the NIC > to honor them, e.g.: > > # ifconfig ax0 -txcsum -rxcsum -tso4 -tso6 -lro -txcsum6 -rxcsum6 > # ifconfig ax1 -txcsum -rxcsum -tso4 -tso6 -lro -txcsum6 -rxcsum6 > Earlier, I haven't tried disabling the Offload capabilities. But I tried now, but it still behaves the same way. ARP replies doesn't seem to reach the bridge (or dropped) to be forwarded. I will collect the details for AMD driver. Tried the same test with another 10G card (Intel "ix" driver) also exhibits similar behavior. Details below. > a) I tried with another vendor 10G NIC card. It behaves the same way. So >> this issue doesn't seem to be generic and not hardware specific. >> > > Which driver are those NICs using? That makes the difference. I guess it's > still a driver with no native netmap support, hence > you are using the same emulated adapter > I am using the "ix" driver (Intel 10G NIC adapter). I guess this driver also doesn't support Native Netmap. Please correct me if I am wrong. I tried disabling the offload capabilities with this device/driver and tested and still observed the netmap bridging fails. root@fbsd_cur# sysctl dev.ix.0 | grep tx_packets dev.ix.0.queue7.tx_packets: 0 dev.ix.0.queue6.tx_packets: 0 dev.ix.0.queue5.tx_packets: 0 dev.ix.0.queue4.tx_packets: 0 dev.ix.0.queue3.tx_packets: 0 dev.ix.0.queue2.tx_packets: 0 dev.ix.0.queue1.tx_packets: 0 *dev.ix.0.queue0.tx_packets: 3* root@fbsd_cur# sysctl dev.ix.0 | grep rx_packets dev.ix.0.queue7.rx_packets: 0 dev.ix.0.queue6.rx_packets: 0 dev.ix.0.queue5.rx_packets: 0 dev.ix.0.queue4.rx_packets: 0 dev.ix.0.queue3.rx_packets: 0 dev.ix.0.queue2.rx_packets: 0 dev.ix.0.queue1.rx_packets: 0 dev.ix.0.queue0.rx_packets: 0 root@fbsd_cur # sysctl dev.ix.1 | grep tx_packets dev.ix.1.queue7.tx_packets: 0 dev.ix.1.queue6.tx_packets: 0 dev.ix.1.queue5.tx_packets: 0 dev.ix.1.queue4.tx_packets: 0 dev.ix.1.queue3.tx_packets: 0 dev.ix.1.queue2.tx_packets: 0 dev.ix.1.queue1.tx_packets: 0 dev.ix.1.queue0.tx_packets: 0 root@fbsd_cur # sysctl dev.ix.1 | grep rx_packets dev.ix.1.queue7.rx_packets: 0 dev.ix.1.queue6.rx_packets: 0 dev.ix.1.queue5.rx_packets: 0 dev.ix.1.queue4.rx_packets: 0 dev.ix.1.queue3.rx_packets: 0 dev.ix.1.queue2.rx_packets: 0 dev.ix.1.queue1.rx_packets: 0 *dev.ix.1.queue0.rx_packets: 3* You can see "ix1" received 3 packets (ARP requests) from system 1 and transmitted 3 packets to system 2 via "ix0". But ARP reply from system 2 is not captured or forwared properly. You can see the checksum features disabled (except VLAN_HWCSIM) on both interfaces. And you can see both interfaces active and Link up. root@fbsd_cur # ifconfig -a ix0: flags=8862 metric 0 mtu 1500 options=48538b8 ether a0:36:9f:a5:49:90 media: Ethernet autoselect (100baseTX ) status: active nd6 options=29 ix1: flags=8862 metric 0 mtu 1500 options=48538b8 ether a0:36:9f:a5:49:92 media: Ethernet autoselect (1000baseT ) status: active nd6 options=29 > > b) Trying with another vendor 1G NIC card, things are working. So not >> sure, what makes a difference here. The ports in System 1 and System 2 >> are >> USB attached Ethernet capable of maximum speed of 1G. So does connecting >> 1G to 10G bridge ports is having any impact? >> > > I don't think so. On each p2p link the NICs will negotiate 1G speed. > In any case, what driver was this one? > This is "igb" driver. Intel 1G NIC Card. Thanks, Rajesh. From owner-freebsd-hackers@freebsd.org Thu Nov 19 12:05:44 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 322F446A2B5 for ; Thu, 19 Nov 2020 12:05:44 +0000 (UTC) (envelope-from antranigv@freebsd.am) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CcJKh0nCJz4bsN for ; Thu, 19 Nov 2020 12:05:44 +0000 (UTC) (envelope-from antranigv@freebsd.am) Received: by mail-ed1-x532.google.com with SMTP id k4so5589541edl.0 for ; Thu, 19 Nov 2020 04:05:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd-am.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=hcobvkaJqV7Kz+ILeoJ0AFoubBcJdFPr/p5uOPc5Kao=; b=AJM2lQeuqzAfMgSkQWkowl5gWnkYq1kd+db3CfhluDlTSX99bQYdgnrpM9r02AcXl8 XBiDvBffyqtnU3vg+vGVuDr8IfR/m0ucs1rvGHuuGriiihPLg9h5wnILgcfZRAzTh9bF d/tadO/xpOIE1eRSOnZXvRthaBYG5ntqdOGY467d61JjtiP3e2gjWOv3Ux8+22C3bzj8 akFF9Jcf9DSfT4R/0/er67CIdML2UaOssUfJbAqZAtyw7W8NNAIO/+N39bEwqu2sUNoh bDeTf3uV1djvgC44at3Usw4eBhIywvjHAFZAO0FdgTUsZLf0yN5eSXltNp9RM0838t0X 3AGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=hcobvkaJqV7Kz+ILeoJ0AFoubBcJdFPr/p5uOPc5Kao=; b=KMJNXdLqU032p1qTrFJyJvFkJweT/iYqKTusJYWGb6+i2i+LI9F4pYLq4sTLCld/Ou /QvB3UQDHbLyyIAsWCF2k6uAu1MxMu5DdkTks689MV3nXj/7VGO2FWPYKvIbXDG3Aoqd O1yC9euWGGLhf5qk6UVTqCqnwEyFKYq8laOkBn1oX5cj48z+kPey5yf/TFud6Ov32pMV GpU3hQOlYqC5IhHdH8ATLv9WTHCBqrwk8g1mHH8ko3a1d0mc5q/9LIVPOivZk5eJNk50 GXzBsek1f8Hv1X6Qi1Me7Nvj5iaTqQ5r8z3hYx7Sp9au1YPxVnzmJWLaSU3BOO31HbTH PBlQ== X-Gm-Message-State: AOAM533DP3PTSFvqWOsVz8QC3z0Gv3slw7gq8Arboc/lUTEEPpuvllkV Dc0GhUco7f9x5W8J4KNWgcvV5IsyKxQozA== X-Google-Smtp-Source: ABdhPJwPJDGulxIqEE33YuyPjX8jjqu/xsLHyqu+YybaF4/Z0jgpsUAP+5MxTz3jzUCdrtFIra66BQ== X-Received: by 2002:aa7:c916:: with SMTP id b22mr19595491edt.267.1605787542186; Thu, 19 Nov 2020 04:05:42 -0800 (PST) Received: from [192.168.6.98] ([141.136.88.213]) by smtp.gmail.com with ESMTPSA id e12sm580139edm.48.2020.11.19.04.05.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 19 Nov 2020 04:05:41 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Antranig Vartanian Mime-Version: 1.0 (1.0) Subject: Re: How is Thunderbird signing my emails? Date: Thu, 19 Nov 2020 16:05:40 +0400 Message-Id: <7CB521CC-8B8D-4E06-BBE0-23FD58A2F79F@freebsd.am> References: <3e4179d0-f6c4-66a5-9628-b2ee95071858@FreeBSD.org> Cc: freebsd-hackers@freebsd.org In-Reply-To: <3e4179d0-f6c4-66a5-9628-b2ee95071858@FreeBSD.org> To: lev@freebsd.org X-Mailer: iPhone Mail (18B92) X-Rspamd-Queue-Id: 4CcJKh0nCJz4bsN X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 12:05:44 -0000 I=E2=80=99m wondering if there are any alternative clients that Just Works a= nd uses GnuPG keyring? Thanks in advance.=20 Sent from my iPhone > On 19 Nov 2020, at 3:02 PM, Lev Serebryakov wrote: >=20 > =EF=BB=BFOn 19.11.2020 5:52, George Mitchell wrote: >=20 >> The Thunderbird people have integrated the functionality of Enigmail >> into Thunderbird itself. In the abstract, this sounds like a great >> idea, because I believe that the more people use PGP signatures and >> encryption, the better. But the concrete reality of the implementation >> puzzles me in a couple of respects: > Concrete reality of the implementation is awful. It is not replacement for= Enigmail :-( >=20 >> a. It's now inclined to attach my public key to every message I send, >> unless I tell it it not to do that on a message-by-message basis (under >> the "Security" menu in the message composition dialog). I can't find >> where I can globally disable this. > See https://bugzilla.mozilla.org/show_bug.cgi?id=3D1654950 - new releases w= ill have hidden setting for it. >=20 >> b. More alarmingly, when it appends my PGP signature to my outgoing >> messages, it is able to unlock my private key without asking for the >> passphrase. How is it doing this?? > New Thunderbird doesn't use GPG keyring, it imports all keys into its own d= atabase (also it doesn't use Web Of Trust!). Private keys are protected only= by global profile password (did you have this one set? I'm in doubt, it is= rarely-used feature). So, if you account is without global password, you im= ported private keys are not protected at all. Good luck with that :-( >=20 > --=20 > // Lev Serebryakov > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"= From owner-freebsd-hackers@freebsd.org Thu Nov 19 13:48:35 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0D0FE46C31A for ; Thu, 19 Nov 2020 13:48:35 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CcLcK43b5z4h0w for ; Thu, 19 Nov 2020 13:48:33 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: by mail-wm1-x32d.google.com with SMTP id c9so7246267wml.5 for ; Thu, 19 Nov 2020 05:48:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=/J1/4sFw7I8sIGXlJxDfePqjQ7ML0wcBK7xOaSwnvgs=; b=YMf1JTixhAjUcElpeQetk2JpYBYg5Ns+IE4Ipbr8OhYLsYgZZiTlbiZihEfzJt10m7 geqtCzJf/MoHlnfM1FjMa9R+Dw5buAO7eXqxTaFIC5k1o1gWCL2nHilLeMXtonJRrd52 rKuIHxiwJDEoNEtL2gLnL2ZU0qO45tWNgo/z5S/8TadO71KhWCB1nCBrVZ3Pr8hO26YB sbpBI1Kt58GBLWoNUhKvyht6vTlNn8aU4soTttrjv59FJ4qjKDZvoQlaLQyeK0Eoz4iv e8b9w7VavLp3fpB2ZPgadkBC9k6tU6nDA6G9ppMVnVGFjFnMfkUI6umufncvmkKKftqr HRMw== X-Gm-Message-State: AOAM532m3FvmbZsFeqnUA923vfVX6ojQiAQ4j0D1udwQ5es45Im+I0qp eLDRGnMyZ3gX1U+68rzrwrWU2tsyYPyucQ== X-Google-Smtp-Source: ABdhPJwGqsDzkUOwQeVE3LAw4zczdKgewoVZsOh1aANbkR0UW2kL1VHrkKYzX6ULJyD/PCHbBYozbQ== X-Received: by 2002:a1c:a752:: with SMTP id q79mr4578005wme.24.1605793711885; Thu, 19 Nov 2020 05:48:31 -0800 (PST) Received: from gumby.homeunix.com ([2.220.20.221]) by smtp.gmail.com with ESMTPSA id y2sm3937999wrn.31.2020.11.19.05.48.30 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Nov 2020 05:48:31 -0800 (PST) Date: Thu, 19 Nov 2020 13:48:26 +0000 From: RW To: freebsd-hackers@freebsd.org Subject: Re: How is Thunderbird signing my emails? Message-ID: <20201119134826.12a372d4@gumby.homeunix.com> In-Reply-To: <9e617638-0bd9-52cd-c361-8d73633d9bab@m5p.com> References: <9e617638-0bd9-52cd-c361-8d73633d9bab@m5p.com> X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; amd64-portbld-freebsd12.1) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4CcLcK43b5z4h0w X-Spamd-Bar: -- X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[googlemail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[googlemail.com:+]; DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RECEIVED_SPAMHAUS_PBL(0.00)[2.220.20.221:received]; SUBJECT_ENDS_QUESTION(1.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::32d:from]; FREEMAIL_ENVFROM(0.00)[googlemail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[googlemail.com:s=20161025]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[googlemail.com:dkim]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::32d:from:127.0.2.255]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::32d:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 13:48:35 -0000 On Wed, 18 Nov 2020 21:52:59 -0500 George Mitchell wrote: > The Thunderbird people have integrated the functionality of Enigmail > into Thunderbird itself. In the abstract, this sounds like a great > idea, because I believe that the more people use PGP signatures and > encryption, the better. IMO this article makes some good points about that: https://latacora.micro.blog/2020/02/19/stop-using-encrypted.html From owner-freebsd-hackers@freebsd.org Thu Nov 19 17:15:49 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D5DD947041B for ; Thu, 19 Nov 2020 17:15:49 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CcRCT5T1Sz4tw9 for ; Thu, 19 Nov 2020 17:15:49 +0000 (UTC) (envelope-from debdrup@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1605806149; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=gvNSeSwsvaLEVreg5gov3TgYiPUDTcjnieogsQet1Eg=; b=koLMDjZ3NBl8pObT3/3kS48fm0GY+WCw6tkEH/mM2HWBem+wZcwPvNVY/371+G+1TzU1/B bisOvV0bJCDPBFcG5AZ8Bqdog0CEEXjNJLnp/ATZX+5wOmifBGQEs+B/652DqHhtKyHq+E Kkd4JX7oM1fqV3UwwpbeYhtO/KQd41Ih/tuT+mV9BJnOEhmuOtRp8U8RV5Ju61EQmCwUW3 LJvMANsUqkNljJxQpbLyOzraJctGYtRfWVA8ktinBpodRBW5eZppCsvwn5fvy4jzhnp4Ft y6rpuZLYxS1u2hMJVBZI4HGBuG9rHTLUZn+UgYRTf1zSFH1YfC3wntJmENV5Fg== Received: by freefall.freebsd.org (Postfix, from userid 1471) id AE9B0B0C5; Thu, 19 Nov 2020 17:15:49 +0000 (UTC) Date: Thu, 19 Nov 2020 18:15:48 +0100 From: Daniel Ebdrup Jensen To: freebsd-hackers@freebsd.org Subject: Re: How is Thunderbird signing my emails? Message-ID: <20201119171548.anb34fpeuij3liyr@nerd-thinkpad.local> Mail-Followup-To: Daniel Ebdrup Jensen , freebsd-hackers@freebsd.org References: <3e4179d0-f6c4-66a5-9628-b2ee95071858@FreeBSD.org> <7CB521CC-8B8D-4E06-BBE0-23FD58A2F79F@freebsd.am> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="lutftm3h3tq73gxs" Content-Disposition: inline In-Reply-To: <7CB521CC-8B8D-4E06-BBE0-23FD58A2F79F@freebsd.am> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1605806149; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=gvNSeSwsvaLEVreg5gov3TgYiPUDTcjnieogsQet1Eg=; b=vnLMx7JozVZkrw+gEQY1qqOhaLngUKZp3iIiBLZ0dg5+JJQC+/KnG89u/Bd3ObwbqH5Wkr JDlGZXQHpl8VJHr4aQNH6gjbtF3DShdsgJTYlPNR3AQ6QQoAzlCA8Byen/jAVMgZ++bCjK LQbsBv2+pDFf2KRTtEUE4vrrNRfGNcBtL9piyrUV3dzHOnNs0LWiIBFZMXSmAXAHQOeLNp Y5FcruwBgoWIQpUHZXtEui0PSXZdhC6EhTSBy1M8N1gu80s+8RMpP6ADS8UBGXKyElZwbg 8epuVUW76gHwLAxhWM60x6TSCQCmREezi3JpgKPLOo8Zjfq0iNWSpuIMC5QslA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1605806149; a=rsa-sha256; cv=none; b=wyuntJGYz2LqcNiTqI20k/7Gd1bl8X8BKy581APcxRlrM7cFBDXpFytndc6k9drta+R/QP P/ljibFtw+J697Dx83AREkGA6ljrd3B12U2PRCjn3mGKeerHgNkdglPd7nakYC+SG4QhLC TJ6oGlhUlexTiJgo2v6hfMI3c4Gda73pcyHKE7Sh7JnCqSXJBJcvku5Wdg8eXdroSwKgZa z97a8LMh2NH2jQ2I5oA12NgWDaMsnLr3L7cGjrTBOgQB0NkmeYX78Y6XQmg2gi2l4f9aNj SEoot6W+bWmS/CE2lFmj9zux8Nv+m76H3C8tj6ihZFa3+SotLFakmgda39mkqg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 17:15:49 -0000 --lutftm3h3tq73gxs Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 19, 2020 at 04:05:40PM +0400, Antranig Vartanian wrote: >I=E2=80=99m wondering if there are any alternative clients that Just Works= and uses GnuPG keyring? > >Thanks in advance. > >Sent from my iPhone > >> On 19 Nov 2020, at 3:02 PM, Lev Serebryakov wrote: >> >> =EF=BB=BFOn 19.11.2020 5:52, George Mitchell wrote: >> >>> The Thunderbird people have integrated the functionality of Enigmail >>> into Thunderbird itself. In the abstract, this sounds like a great >>> idea, because I believe that the more people use PGP signatures and >>> encryption, the better. But the concrete reality of the implementation >>> puzzles me in a couple of respects: >> Concrete reality of the implementation is awful. It is not replacement f= or Enigmail :-( >> >>> a. It's now inclined to attach my public key to every message I send, >>> unless I tell it it not to do that on a message-by-message basis (under >>> the "Security" menu in the message composition dialog). I can't find >>> where I can globally disable this. >> See https://bugzilla.mozilla.org/show_bug.cgi?id=3D1654950 - new release= s will have hidden setting for it. >> >>> b. More alarmingly, when it appends my PGP signature to my outgoing >>> messages, it is able to unlock my private key without asking for the >>> passphrase. How is it doing this?? >> New Thunderbird doesn't use GPG keyring, it imports all keys into its ow= n database (also it doesn't use Web Of Trust!). Private keys are protected = only by global profile password (did you have this one set? I'm in doubt, i= t is rarely-used feature). So, if you account is without global password, = you imported private keys are not protected at all. Good luck with that :-( >> >> -- >> // Lev Serebryakov >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.or= g" >_______________________________________________ >freebsd-hackers@freebsd.org mailing list >https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" Hi folks, NeoMutt and GnuPG works well together, and NeoMutt can even render html ema= il by=20 using w3m as a pager for the by setting 'auto_view text/html' and putting t= he=20 following into ~/.mailcap: text/html; w3m -T text/html %s; nametemplate=3D%s.html; copiousoutput I've been using it on my FreeBSD laptop for both mailing lists, FreeBSD=20 development, and as a daily driver. Also, please think of this as a little reminder not to top-post on mailing= =20 lists. :) Yours respectfully, Daniel Ebdrup Jensen --lutftm3h3tq73gxs Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEEDonNJPbg/JLIMoS6Ps5hSHzN87oFAl+2qENfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDBF ODlDRDI0RjZFMEZDOTJDODMyODRCQTNFQ0U2MTQ4N0NDREYzQkEACgkQPs5hSHzN 87qnPggAo6PzXLT+8PEFEQyUgltqQCN1/CLAcsRsgcvo9kWwTLprvQN1DqTsX37r Pr8K8KXjUyD6jk0SFd5FSPV/xPh33dGjiPDS/OCh368UIES1kacFrY3ZScX9hTkS kNqpyLIuF1j5JxazxvMeVCkHw2pT78mfcDO3OJ5h3d+o37R4yeuY0MeBYwrB1Oi9 7iZ5Xp8R8iHEZVH9A+09l1TnY6t0H5DCyq4KellX93BcC8EYh32ROJu2IZjC/twh J53haiibWRSAkLYt6g9e1WdAOt1o+/GnjEevj6AQNGdVmy+JXdJ/TTE9ofha8au0 zp0rC0O0EBbx9jjhcMT+qzlPMgy/rA== =IXf8 -----END PGP SIGNATURE----- --lutftm3h3tq73gxs-- From owner-freebsd-hackers@freebsd.org Thu Nov 19 19:22:21 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 35D75472C9A for ; Thu, 19 Nov 2020 19:22:21 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "m5p.com", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CcV1S4XV7z3Jpj for ; Thu, 19 Nov 2020 19:22:20 +0000 (UTC) (envelope-from george+freebsd@m5p.com) Received: from [IPv6:2001:470:1f07:15ff::26] (court.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:26]) (authenticated bits=0) by mailhost.m5p.com (8.15.2/8.15.2) with ESMTPSA id 0AJJMDXY012611 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Thu, 19 Nov 2020 14:22:18 -0500 (EST) (envelope-from george+freebsd@m5p.com) Subject: Re: How is Thunderbird signing my emails? To: freebsd-hackers@freebsd.org References: <3e4179d0-f6c4-66a5-9628-b2ee95071858@FreeBSD.org> <7CB521CC-8B8D-4E06-BBE0-23FD58A2F79F@freebsd.am> <20201119171548.anb34fpeuij3liyr@nerd-thinkpad.local> From: George Mitchell Message-ID: Date: Thu, 19 Nov 2020 14:22:12 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: <20201119171548.anb34fpeuij3liyr@nerd-thinkpad.local> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="13CJvmGTuU9akqrXyS1k7zH1nmyh6G3Nc" X-Spam-Status: No, score=-0.3 required=10.0 tests=HELO_MISC_IP, HELO_NO_DOMAIN, NICE_REPLY_A autolearn=unavailable autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mattapan.m5p.com X-Rspamd-Queue-Id: 4CcV1S4XV7z3Jpj X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of george@m5p.com designates 74.104.188.4 as permitted sender) smtp.mailfrom=george@m5p.com X-Spamd-Result: default: False [-4.40 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+a:c]; HAS_ATTACHMENT(0.00)[]; TO_DN_NONE(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:+,5:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[74.104.188.4:from]; ASN(0.00)[asn:701, ipnet:74.104.0.0/16, country:US]; R_DKIM_NA(0.00)[]; TAGGED_FROM(0.00)[freebsd]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain,application/pgp-keys]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[m5p.com]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[74.104.188.4:from:127.0.2.255]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers] X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 19:22:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --13CJvmGTuU9akqrXyS1k7zH1nmyh6G3Nc Content-Type: multipart/mixed; boundary="zp7MTH2ij6xZTg9PhhTt6d6R6NfS8FIQN"; protected-headers="v1" From: George Mitchell To: freebsd-hackers@freebsd.org Message-ID: Subject: Re: How is Thunderbird signing my emails? References: <3e4179d0-f6c4-66a5-9628-b2ee95071858@FreeBSD.org> <7CB521CC-8B8D-4E06-BBE0-23FD58A2F79F@freebsd.am> <20201119171548.anb34fpeuij3liyr@nerd-thinkpad.local> In-Reply-To: <20201119171548.anb34fpeuij3liyr@nerd-thinkpad.local> --zp7MTH2ij6xZTg9PhhTt6d6R6NfS8FIQN Content-Type: multipart/mixed; boundary="------------27E28617A44FDB675DA14B6B" Content-Language: en-US This is a multi-part message in MIME format. --------------27E28617A44FDB675DA14B6B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 11/19/20 12:15 PM, Daniel Ebdrup Jensen wrote: > On Thu, Nov 19, 2020 at 04:05:40PM +0400, Antranig Vartanian wrote: >> I=E2=80=99m wondering if there are any alternative clients that Just = Works=20 and uses GnuPG keyring? >> >> Thanks in advance. >> >> Sent from my iPhone >> >>> On 19 Nov 2020, at 3:02 PM, Lev Serebryakov wrote:= >>> >>> =EF=BB=BFOn 19.11.2020 5:52, George Mitchell wrote: >>> >>>> The Thunderbird people have integrated the functionality of Enigmai= l >>>> into Thunderbird itself. In the abstract, this sounds like a great= >>>> idea, because I believe that the more people use PGP signatures and= >>>> encryption, the better. But the concrete reality of the=20 implementation >>>> puzzles me in a couple of respects: >>> Concrete reality of the implementation is awful. It is not=20 replacement for Enigmail :-( >>> >>>> a. It's now inclined to attach my public key to every message I sen= d, >>>> unless I tell it it not to do that on a message-by-message basis=20 (under >>>> the "Security" menu in the message composition dialog). I can't fi= nd >>>> where I can globally disable this. >>> See https://bugzilla.mozilla.org/show_bug.cgi?id=3D1654950 - new=20 releases will have hidden setting for it. >>> >>>> b. More alarmingly, when it appends my PGP signature to my outgoing= >>>> messages, it is able to unlock my private key without asking for th= e >>>> passphrase. How is it doing this?? >>> New Thunderbird doesn't use GPG keyring, it imports all keys into=20 its own database (also it doesn't use Web Of Trust!). Private keys are=20 protected only by global profile password (did you have this one set?=20 I'm in doubt, it is rarely-used feature). So, if you account is without = global password, you imported private keys are not protected at all.=20 Good luck with that :-( >>> >>> -- >>> // Lev Serebryakov >>> _______________________________________________ >>> freebsd-hackers@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>> To unsubscribe, send any mail to=20 "freebsd-hackers-unsubscribe@freebsd.org" >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to=20 "freebsd-hackers-unsubscribe@freebsd.org" > > Hi folks, > > NeoMutt and GnuPG works well together, and NeoMutt can even render=20 html email by using w3m as a pager for the by setting 'auto_view=20 text/html' and putting the following into ~/.mailcap: > text/html; w3m -T text/html %s; nametemplate=3D%s.html; copiousoutput > > I've been using it on my FreeBSD laptop for both mailing lists,=20 FreeBSD development, and as a daily driver. > > Also, please think of this as a little reminder not to top-post on=20 mailing lists. :) > > Yours respectfully, > Daniel Ebdrup Jensen Thanks to all for the information. I've been pondering Signal for a while now (thanks to RW for the blog post about avoiding encrypted email altogether). -- George --------------27E28617A44FDB675DA14B6B-- --zp7MTH2ij6xZTg9PhhTt6d6R6NfS8FIQN-- --13CJvmGTuU9akqrXyS1k7zH1nmyh6G3Nc Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEENdM4ZHktsJW5kKZXwRES3m+p4fkFAl+2xeQFAwAAAAAACgkQwRES3m+p4fnJ oRAAu1i5VEkOx1UooH82kOUtsoV/2fiqz135EHdJ38uT2w7DsN1uZbiOlDUoF0emDtISRdIWApEl HTmbWKzMTRgV8qzt40PXnvlYPFarIy6Bc66NLGT+3+SpJmyeOVoUsLbNu6v6z2d7pJ+tWbqRWC8b nOE8ZEIIA0A5n5QSpvkMEGchVly+gKxJcBpEsREHrCotiptyC+BKBuYv9/fi5/UdI6dnnzv2T+sy O6YmQbZrkaQTL90WFBqTLZGz7F+J7TDgg8bXWA1ua1STdm2DFSyyoQ3x+eWIGIrESEQc+8gXOewI 4oJ1BaxXIjslVRakRu79fO/A4DmubtPgANAHeKTDuCJasCbU/4lHPIkcB9bHf6jDBTiPKrIygW7S Huza+vSpl4Rx/OEMt3uJs5NzmTnwpIGbQ823IQqNm9IOktqCS+y0S/OkTDmay/gcltTXxIdKlXjM BsSAvyCK1fAl4xd0UTwAmDMjSrXB5SVMliF/ScE2OFGkqS363jUkf/GcgpvhFmS1OqhnHoMy+B7k 8mcfAkbN5F9CZmnpqBGdCakTCNqVnZYs6NAEBw/B4sPLJQcjJ5EAGciEilz3IVSpnrFrPDjEVTY3 1Bu9Sk/thmPD+c3g43GOF6RwmLjrZ8LsZWfSOrFMeHCLchghHsJ/pa7I3QyIVklBi4GnfIq7nGKy D8c= =zByL -----END PGP SIGNATURE----- --13CJvmGTuU9akqrXyS1k7zH1nmyh6G3Nc-- From owner-freebsd-hackers@freebsd.org Thu Nov 19 21:50:30 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5CA49475BD5; Thu, 19 Nov 2020 21:50:30 +0000 (UTC) (envelope-from vmaffione@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CcYJQ27xGz3hbl; Thu, 19 Nov 2020 21:50:30 +0000 (UTC) (envelope-from vmaffione@freebsd.org) Received: from mail-pg1-f181.google.com (mail-pg1-f181.google.com [209.85.215.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: vmaffione) by smtp.freebsd.org (Postfix) with ESMTPSA id 330A0775E; Thu, 19 Nov 2020 21:50:30 +0000 (UTC) (envelope-from vmaffione@freebsd.org) Received: by mail-pg1-f181.google.com with SMTP id m9so5464693pgb.4; Thu, 19 Nov 2020 13:50:30 -0800 (PST) X-Gm-Message-State: AOAM532nPHvAjZHt4g33uvYxgMh9IaimwHwGT5yQM3RcYgFvHGdeUOiX m4MjldI/qgZs2SfvvGvoPReh1siqvZvKLHmiJwQ= X-Google-Smtp-Source: ABdhPJxkWhUT7ndeg0YXYrdmVME254+XCg4pAlvO3R1NXIsWdWiL2g3HxMGliqfBKsr1GNRIyIjK9ugoKDZGJ6TtvU4= X-Received: by 2002:a63:d650:: with SMTP id d16mr13835611pgj.277.1605822629178; Thu, 19 Nov 2020 13:50:29 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Vincenzo Maffione Date: Thu, 19 Nov 2020 22:50:17 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Netmap bridge not working with 10G Ethernet ports To: Rajesh Kumar Cc: "freebsd-net@freebsd.org" , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 21:50:30 -0000 Il giorno gio 19 nov 2020 alle ore 12:28 Rajesh Kumar ha scritto: > Hi Vincenzo, > > Thanks for your reply. > > On Thu, Nov 19, 2020 at 3:16 AM Vincenzo Maffione > wrote: > >> >> This looks like if_axe(4) driver, and therefore there's no native netmap >> support, which means you are falling back on >> the emulated netmap adapter. Are these USB dongles? If so, how can they >> be 10G? >> > > The Driver I am working with is "if_axp" (sys/dev/axgbe). This is AMD > 10Gigabit Ethernet Driver. This is recently committed upstream. Yes, it > doesn't have a Native netmap support, but uses the netmap stack which is > existing already. These are inbuilt SFP ports with our test board and not > USB dongles. > Ok, now it makes sense. Thanks for clarifying. I see that if_axp(4) uses iflib(4). This means that actually if_axp(4) has native netmap support, because iflib(4) has native netmap support. > Does Native netmap mean the hardware capability which needs to be > programmed appropriately from driver side? Any generic documentation > regarding the same? > It means that the driver has some modifications to allow netmap to directly program the NIC rings. These modifications are mostly the per-driver txsync and rxsyng routines. In case of iflib(4) drivers, these modifications are provided directly within the iflib(4) code, and therefore any driver using iflib will have native netmap support. > >> In this kind of configuration it is mandatory to disable all the NIC >> offloads, because netmap does not program the NIC >> to honor them, e.g.: >> >> # ifconfig ax0 -txcsum -rxcsum -tso4 -tso6 -lro -txcsum6 -rxcsum6 >> # ifconfig ax1 -txcsum -rxcsum -tso4 -tso6 -lro -txcsum6 -rxcsum6 >> > > Earlier, I haven't tried disabling the Offload capabilities. But I tried > now, but it still behaves the same way. ARP replies doesn't seem to reach > the bridge (or dropped) to be forwarded. I will collect the details for > AMD driver. Tried the same test with another 10G card (Intel "ix" driver) > also exhibits similar behavior. Details below. > Ok, this makes sense, because also ix(4) uses iflib, and therefore you are basically hitting the same issue of if_axp(4) At this point I must think that there is still some issue with the interaction between iflib(4) and netmap(4). > > >> a) I tried with another vendor 10G NIC card. It behaves the same way. So >>> this issue doesn't seem to be generic and not hardware specific. >>> >> >> Which driver are those NICs using? That makes the difference. I guess >> it's still a driver with no native netmap support, hence >> you are using the same emulated adapter >> > > I am using the "ix" driver (Intel 10G NIC adapter). I guess this driver > also doesn't support Native Netmap. Please correct me if I am wrong. I > tried disabling the offload capabilities with this device/driver and tested > and still observed the netmap bridging fails. > As I stated above, ix(4) has netmap support, like any iflib(4) driver. > root@fbsd_cur# sysctl dev.ix.0 | grep tx_packets > dev.ix.0.queue7.tx_packets: 0 > dev.ix.0.queue6.tx_packets: 0 > dev.ix.0.queue5.tx_packets: 0 > dev.ix.0.queue4.tx_packets: 0 > dev.ix.0.queue3.tx_packets: 0 > dev.ix.0.queue2.tx_packets: 0 > dev.ix.0.queue1.tx_packets: 0 > *dev.ix.0.queue0.tx_packets: 3* > root@fbsd_cur# sysctl dev.ix.0 | grep rx_packets > dev.ix.0.queue7.rx_packets: 0 > dev.ix.0.queue6.rx_packets: 0 > dev.ix.0.queue5.rx_packets: 0 > dev.ix.0.queue4.rx_packets: 0 > dev.ix.0.queue3.rx_packets: 0 > dev.ix.0.queue2.rx_packets: 0 > dev.ix.0.queue1.rx_packets: 0 > dev.ix.0.queue0.rx_packets: 0 > root@fbsd_cur # sysctl dev.ix.1 | grep tx_packets > dev.ix.1.queue7.tx_packets: 0 > dev.ix.1.queue6.tx_packets: 0 > dev.ix.1.queue5.tx_packets: 0 > dev.ix.1.queue4.tx_packets: 0 > dev.ix.1.queue3.tx_packets: 0 > dev.ix.1.queue2.tx_packets: 0 > dev.ix.1.queue1.tx_packets: 0 > dev.ix.1.queue0.tx_packets: 0 > root@fbsd_cur # sysctl dev.ix.1 | grep rx_packets > dev.ix.1.queue7.rx_packets: 0 > dev.ix.1.queue6.rx_packets: 0 > dev.ix.1.queue5.rx_packets: 0 > dev.ix.1.queue4.rx_packets: 0 > dev.ix.1.queue3.rx_packets: 0 > dev.ix.1.queue2.rx_packets: 0 > dev.ix.1.queue1.rx_packets: 0 > > *dev.ix.1.queue0.rx_packets: 3* > > You can see "ix1" received 3 packets (ARP requests) from system 1 and > transmitted 3 packets to system 2 via "ix0". But ARP reply from system 2 is > not captured or forwared properly. > I see. This info may be useful. Have you tried to look at interrupts (e.g. `vmstat -i`), to see if "ix0" gets any RX interrupts (for the missing ARP replies)? > > You can see the checksum features disabled (except VLAN_HWCSIM) on both > interfaces. And you can see both interfaces active and Link up. > > root@fbsd_cur # ifconfig -a > ix0: flags=8862 metric 0 mtu 1500 > > options=48538b8 > ether a0:36:9f:a5:49:90 > media: Ethernet autoselect (100baseTX ) > status: active > nd6 options=29 > > ix1: flags=8862 metric 0 mtu 1500 > > options=48538b8 > ether a0:36:9f:a5:49:92 > media: Ethernet autoselect (1000baseT > ) > status: active > nd6 options=29 > >> >> b) Trying with another vendor 1G NIC card, things are working. So not >>> sure, what makes a difference here. The ports in System 1 and System 2 >>> are >>> USB attached Ethernet capable of maximum speed of 1G. So does connecting >>> 1G to 10G bridge ports is having any impact? >>> >> >> I don't think so. On each p2p link the NICs will negotiate 1G speed. >> In any case, what driver was this one? >> > > This is "igb" driver. Intel 1G NIC Card. > Also the igb(4) driver is using iflib(4). So the involved netmap code is the same as ix(4) and if_axp(4). This is something that I'm not able to understand right now. It does not look like something related to offloads. Next week I will try to see if I can reproduce your issue with em(4), and report back. That's still an Intel driver using iflib(4). Thanks, Vincenzo > > Thanks, > Rajesh. > From owner-freebsd-hackers@freebsd.org Fri Nov 20 11:35:21 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8B9502C6ED1 for ; Fri, 20 Nov 2020 11:35:21 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ccvc93XY8z3Fjv for ; Fri, 20 Nov 2020 11:35:21 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.not-for.work (onlyone.not-for.work [IPv6:2a01:4f8:201:6350::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: lev/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 52B16E1F7 for ; Fri, 20 Nov 2020 11:35:21 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [192.168.23.230] (unknown [89.113.128.32]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id E1CF72DAB for ; Fri, 20 Nov 2020 14:35:17 +0300 (MSK) Reply-To: lev@FreeBSD.org Subject: Re: How is Thunderbird signing my emails? To: freebsd-hackers@freebsd.org References: <9e617638-0bd9-52cd-c361-8d73633d9bab@m5p.com> <20201119134826.12a372d4@gumby.homeunix.com> From: Lev Serebryakov Organization: FreeBSD Message-ID: <83fe7c1e-d404-4e9d-bfbb-e62824118af9@FreeBSD.org> Date: Fri, 20 Nov 2020 14:35:17 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: <20201119134826.12a372d4@gumby.homeunix.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 11:35:21 -0000 On 19.11.2020 16:48, RW via freebsd-hackers wrote: >> The Thunderbird people have integrated the functionality of Enigmail >> into Thunderbird itself. In the abstract, this sounds like a great >> idea, because I believe that the more people use PGP signatures and >> encryption, the better. > > IMO this article makes some good points about that: > > https://latacora.micro.blog/2020/02/19/stop-using-encrypted.html This post is packed with straw men over the top. But it is offtopic here for sure. -- // Lev Serebryakov From owner-freebsd-hackers@freebsd.org Fri Nov 20 13:31:12 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AD1F22EA877; Fri, 20 Nov 2020 13:31:12 +0000 (UTC) (envelope-from rajfbsd@gmail.com) Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Ccy9r34vsz3NBf; Fri, 20 Nov 2020 13:31:12 +0000 (UTC) (envelope-from rajfbsd@gmail.com) Received: by mail-ot1-x330.google.com with SMTP id y22so8677253oti.10; Fri, 20 Nov 2020 05:31:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4en2qv4i/arwzRLCSEaR6mvJfko42IYgg5QLnPVzn+Y=; b=LzpZ+ReOQ1nRLgTUmfUuVzleNT4/R7tgvNN5z/7AS000hkZVC135Hf8lK9kUwZiFAz 7UG13xgoLwBfANmLkBHpqtwPF0YXAp4Bn9hi5T6JpU6OEnK94fanCUm8a5tyfPiT9yQ+ BidDwZXgZIoQinkUE+iGyqP3TErn3JxB7/46MubihcSQiePROT8eX3Ows7lLO+Rv61uq TtELQj0zjCr18+DC1anxa8zA5754JUs875eYYZlUiIADhmSF96JuBfmqkNGl2c3xATtb jd8Y0ihPSZefHCgwwpgCza8V6d12uNFGKt+Qan/lcbUiEUxlNlqZaxlUqFym7WXt0qgF Dy9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4en2qv4i/arwzRLCSEaR6mvJfko42IYgg5QLnPVzn+Y=; b=o2aTL6vabfKt1bW2zuPNAVucwCrAHB50dLJlj5d2Dc6HIbFUMt5IZzWdtLDAM1L7gs 9whXWsrMBQk0XP4zLJXPZaVdJljwT6i1I0iuwmd10riRHASP7Ie1tOvXsREw69u0VOq/ zTLL2wSlbbMPlurWBqEFIhFKlHnBFcA2ShqC36hHfrxn1Oi8mBKD10TxXw6CVSaqPa8X o3YgQcRIz34Yd5D0ez+OXL4LqfcAavAbS+/TvFnc0V7C1gwxlyvWuudC23qUrKiGdlI6 +4DCT6Y8nKVGeKoFn9LvTci73z7w1T19KA8m6Rf8o2hG+Vebrws6netpeJFKf8/i+mSS bd5g== X-Gm-Message-State: AOAM530HFhDtQ3JOV8H8nV9lHN6TVyw2CQXV2bxZGP4fm3I4H7mb5ojM 6f0cD51XK+fBnLrcZZvMILYHV+wwAT8K1bQ6LsSBJdUjq7s= X-Google-Smtp-Source: ABdhPJzwqeIlDwhfyFPO56tpkRBAKLM2hglPfoTqRWxboSnFq5Wvqv7RoKcnkds94ft9dZ9HOrOvPphodzczyXhMYvU= X-Received: by 2002:a9d:76d7:: with SMTP id p23mr14042591otl.180.1605879071060; Fri, 20 Nov 2020 05:31:11 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Rajesh Kumar Date: Fri, 20 Nov 2020 19:00:59 +0530 Message-ID: Subject: Re: Netmap bridge not working with 10G Ethernet ports To: Vincenzo Maffione Cc: "freebsd-net@freebsd.org" , FreeBSD Hackers , stephan.dewt@yahoo.co.uk X-Rspamd-Queue-Id: 4Ccy9r34vsz3NBf X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 13:31:12 -0000 Hi Vincenzo, On Fri, Nov 20, 2020 at 3:20 AM Vincenzo Maffione wrote: > > Ok, now it makes sense. Thanks for clarifying. I see that if_axp(4) uses > iflib(4). This means that actually if_axp(4) has native netmap support, > because iflib(4) has native netmap support. > > It means that the driver has some modifications to allow netmap to directly > program the NIC rings. These modifications are mostly the per-driver txsync > and rxsyng routines. > In case of iflib(4) drivers, these modifications are provided directly > within the iflib(4) code, and therefore any driver using iflib will have > native netmap support. > Thanks for clarifying on the Native Netmap support. Ok, this makes sense, because also ix(4) uses iflib, and therefore you are > basically hitting the same issue of if_axp(4) > At this point I must think that there is still some issue with the > interaction between iflib(4) and netmap(4). > Ok. Let me know if any more debug info needed in this part. I see. This info may be useful. Have you tried to look at interrupts (e.g. > `vmstat -i`), to see if "ix0" gets any RX interrupts (for the missing ARP > replies)? > It's interesting here. When I try with Intel NIC card. I see atleast 1 interrupt raised. But not sure whether that is for ARP reply. Because, when I try to dump the packet from "bridge"(modified) utility, I don't see any ARP reply packet getting dumped. *irq59: ix0:rxq0 1 0 (only 1 interrupt on the opposite side)*irq67: ix0:aq 2 0 *irq68: ix1:rxq0 3 0 (you can see 3 interrupts for 3 ARP requests from System 1)*irq76: ix1:aq 2 0 The same experiment, when I try with AMD inbuilt ports, I don't see that 1 interrupt also raised. irq81: ax0:dev_irq 16 0 irq83: ax0 2541 4 irq93: ax1:dev_irq 27 0 irq95: ax1 2371 3 *irq97: ax1:rxq0 3 0 (you can see 3 interrupts for 3 ARP requests from System 1, but no interrupt is seen from "ax0:rxq0" for ARP reply from System 2)* I will do some more testing to see whether this behavior is consistent or intermittent. Also the igb(4) driver is using iflib(4). So the involved netmap code is > the same as ix(4) and if_axp(4). > This is something that I'm not able to understand right now. > It does not look like something related to offloads. > > Next week I will try to see if I can reproduce your issue with em(4), and > report back. That's still an Intel driver using iflib(4). > The "igb(4)" driver, with which things are working now is related to em(4) driver (may be for newer hardware version). Initially we faced similar issue with igb(4) driver as well. After reverting the following commits, things started to work. Thanks to Stephan Dewt (copied) for pointing this. But it still fails with ix(4) driver and if_axp(4) driver. https://github.com/freebsd/freebsd/commit/e12efc2c9e434075d0740e2e2e9e2fca2ad5f7cf Thanks for providing your inputs on this issue Vincenzo. Let me know for any more details that you need. Thanks, Rajesh. From owner-freebsd-hackers@freebsd.org Fri Nov 20 14:34:44 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 482E42EC355; Fri, 20 Nov 2020 14:34:44 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Cczb81YR3z3jBh; Fri, 20 Nov 2020 14:34:44 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.codepro.be", Issuer "Let's Encrypt Authority X3" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id E768AF99B; Fri, 20 Nov 2020 14:34:43 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: by venus.codepro.be (Postfix, authenticated sender kp) id 3489F4B6E6; Fri, 20 Nov 2020 15:34:41 +0100 (CET) From: "Kristof Provost" To: "YongHyeon PYUN" Cc: "Carsten =?utf-8?q?B=C3=A4cker?=" , "Hans Petter Selasky" , freebsd-arm@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Problem with checksum offloading on RPi3 (PF + Jails involved) Date: Fri, 20 Nov 2020 15:34:40 +0100 X-Mailer: MailMate (1.13.2r5673) Message-ID: In-Reply-To: <20201119022208.GB1974@michelle> References: <20201103045215.GA2524@michelle> <46d08198-530c-cb4b-efa8-4edaf89471c1@selasky.org> <4dfaa9a3-c085-8466-a6e4-19f988b5ed3d@selasky.org> <20201116011910.GB1941@michelle> <1245cbe5-9d2f-4808-f989-569ae7d57a8a@gmx.de> <20201117030406.GA45158@michelle> <20201118044857.GA1974@michelle> <20201119022208.GB1974@michelle> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 14:34:44 -0000 On 19 Nov 2020, at 3:22, YongHyeon PYUN wrote: > On Wed, Nov 18, 2020 at 10:47:08AM +0100, Carsten Bäcker wrote: > > [...] > >> Sorry, that's my fault - i overlooked your request for a test with pf >> enabled. >> The example-ruleset is attached again. I added a line to allow the >> incoming ping to 5555. >> >> I don't see a difference until i enable the redirection to the jail >> which makes the packet with extended data-length fail. >> Once i disable RXCSUM it works. >> > > Thanks for testing. Unfortunately I couldn't find a driver issue > on patched smsc(4). Quick looking pf(4) makes me wonder how it > verifies UDP datagrams. > > Kristof, does pf(4) take advantage of H/W checksummed result for > UDP datagrams? Yes. Pf updates checksums if they’re present, rather than fully recalculating them. > It seems pf_check_proto_cksum() always pass > IPPROTO_TCP such that UDP pseudo checksum is not computed in the > function. Note that pf_check_proto_cksum() is only ever called from pf_return(), and then only if pf->proto == IPPROTO_TCP. Checksum updates are mostly done through pf_proto_cksum_fixup(), in different parts of the code. Best egards, Kristof From owner-freebsd-hackers@freebsd.org Sat Nov 21 16:06:38 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7F3E8469F70; Sat, 21 Nov 2020 16:06:38 +0000 (UTC) (envelope-from vmaffione@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CddZk374yz4rNL; Sat, 21 Nov 2020 16:06:38 +0000 (UTC) (envelope-from vmaffione@freebsd.org) Received: from mail-pg1-f174.google.com (mail-pg1-f174.google.com [209.85.215.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: vmaffione) by smtp.freebsd.org (Postfix) with ESMTPSA id 54D032B4FD; Sat, 21 Nov 2020 16:06:38 +0000 (UTC) (envelope-from vmaffione@freebsd.org) Received: by mail-pg1-f174.google.com with SMTP id f17so1610276pge.6; Sat, 21 Nov 2020 08:06:38 -0800 (PST) X-Gm-Message-State: AOAM533b+Kbh1yUf1skzGncrjEfmBk4erE3Joim6OBRQCQAqwCplwbeK cQgLjEFKUqJYuDiLHz6OWd5JzBRVFcNu8q2YaVM= X-Google-Smtp-Source: ABdhPJzTruSs1RR5ioxUncuty5+Oj6xQF8Y425PD0r6hdVbKpr9Qmdp+sFyesrCvahiWP82P5cGKRBAq4PjlHA2bD/I= X-Received: by 2002:a17:90a:e615:: with SMTP id j21mr11741439pjy.74.1605974797327; Sat, 21 Nov 2020 08:06:37 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Vincenzo Maffione Date: Sat, 21 Nov 2020 17:06:26 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Netmap bridge not working with 10G Ethernet ports To: Rajesh Kumar Cc: "freebsd-net@freebsd.org" , FreeBSD Hackers , stephan.dewt@yahoo.co.uk Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2020 16:06:38 -0000 Il giorno ven 20 nov 2020 alle ore 14:31 Rajesh Kumar ha scritto: > Hi Vincenzo, > > On Fri, Nov 20, 2020 at 3:20 AM Vincenzo Maffione > wrote: > >> >> Ok, now it makes sense. Thanks for clarifying. I see that if_axp(4) uses >> iflib(4). This means that actually if_axp(4) has native netmap support, >> because iflib(4) has native netmap support. >> >> > It means that the driver has some modifications to allow netmap to >> directly program the NIC rings. These modifications are mostly the >> per-driver txsync and rxsyng routines. >> In case of iflib(4) drivers, these modifications are provided directly >> within the iflib(4) code, and therefore any driver using iflib will have >> native netmap support. >> > > Thanks for clarifying on the Native Netmap support. > > Ok, this makes sense, because also ix(4) uses iflib, and therefore you are >> basically hitting the same issue of if_axp(4) >> At this point I must think that there is still some issue with the >> interaction between iflib(4) and netmap(4). >> > > Ok. Let me know if any more debug info needed in this part. > > I see. This info may be useful. Have you tried to look at interrupts (e.g. >> `vmstat -i`), to see if "ix0" gets any RX interrupts (for the missing ARP >> replies)? >> > > It's interesting here. When I try with Intel NIC card. I see atleast 1 > interrupt raised. But not sure whether that is for ARP reply. Because, > when I try to dump the packet from "bridge"(modified) utility, I don't see > any ARP reply packet getting dumped. > > > *irq59: ix0:rxq0 1 0 (only 1 interrupt on > the opposite side)*irq67: ix0:aq 2 0 > > *irq68: ix1:rxq0 3 0 (you can see 3 > interrupts for 3 ARP requests from System 1)*irq76: ix1:aq > 2 0 > > The same experiment, when I try with AMD inbuilt ports, I don't see that 1 > interrupt also raised. > > irq81: ax0:dev_irq 16 0 > irq83: ax0 2541 4 > irq93: ax1:dev_irq 27 0 > irq95: ax1 2371 3 > *irq97: ax1:rxq0 3 0 (you can see 3 > interrupts for 3 ARP requests from System 1, but no interrupt is seen from > "ax0:rxq0" for ARP reply from System 2)* > > I will do some more testing to see whether this behavior is consistent or > intermittent. > > Also the igb(4) driver is using iflib(4). So the involved netmap code is >> the same as ix(4) and if_axp(4). >> This is something that I'm not able to understand right now. >> It does not look like something related to offloads. >> >> Next week I will try to see if I can reproduce your issue with em(4), and >> report back. That's still an Intel driver using iflib(4). >> > > The "igb(4)" driver, with which things are working now is related to em(4) > driver (may be for newer hardware version). Initially we faced similar > issue with igb(4) driver as well. After reverting the following commits, > things started to work. Thanks to Stephan Dewt (copied) for pointing > this. But it still fails with ix(4) driver and if_axp(4) driver. > > > https://github.com/freebsd/freebsd/commit/e12efc2c9e434075d0740e2e2e9e2fca2ad5f7cf > > Thanks for providing your inputs on this issue Vincenzo. Let me know for > any more details that you need. > > I was able to reproduce your issue on FreeBSD-CURRENT running within a QEMU VM, with two em(4) devices and the netmap bridge running between them. I see the ARP request packet received on em0 (with associated IRQ), and forwarded on em1. However, the ARP reply coming on em1 does not trigger an IRQ on em1, and indeed the NIC RX head/tail pointers are not incremented as they should (`sysctl -a | grep em.1 | grep queue_rx`) ... that is weird, and lets me think that the issue is more likely driver-related than netmap/iflib-related. In any case, would you mind filing the issue on the bugzilla, so that we can properly track this issue? Thanks, Vincenzo > Thanks, > Rajesh. > From owner-freebsd-hackers@freebsd.org Sat Nov 21 17:10:01 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4007F46B6F5; Sat, 21 Nov 2020 17:10:01 +0000 (UTC) (envelope-from vmaffione@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Cdfzs1CPtz4vDl; Sat, 21 Nov 2020 17:10:01 +0000 (UTC) (envelope-from vmaffione@freebsd.org) Received: from mail-pf1-f181.google.com (mail-pf1-f181.google.com [209.85.210.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: vmaffione) by smtp.freebsd.org (Postfix) with ESMTPSA id 1103E2BAB3; Sat, 21 Nov 2020 17:10:01 +0000 (UTC) (envelope-from vmaffione@freebsd.org) Received: by mail-pf1-f181.google.com with SMTP id q5so10926719pfk.6; Sat, 21 Nov 2020 09:10:01 -0800 (PST) X-Gm-Message-State: AOAM531mn7rklCnZnUKdGVSy9dZnN1gIEewmmmI2eEt2Kt10KnEDb9LR mga8A77Cr9KsK2AfNHftYjuHLWqJnfpFKOz4Wo0= X-Google-Smtp-Source: ABdhPJx8Jf7W42lSmVzyWznHbYgvhw/ctIjHNCFDUEbnILzm1Y/hXq1DTcXZHRQHOMJqXWxN8ydtoUSSW3WXjUew3z8= X-Received: by 2002:a63:d650:: with SMTP id d16mr20748756pgj.277.1605978600110; Sat, 21 Nov 2020 09:10:00 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Vincenzo Maffione Date: Sat, 21 Nov 2020 18:09:47 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Netmap bridge not working with 10G Ethernet ports To: Rajesh Kumar Cc: "freebsd-net@freebsd.org" , FreeBSD Hackers , stephan.dewt@yahoo.co.uk Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2020 17:10:01 -0000 Hi Rajesh, I think the issue here is simply that you have not enabled promiscuous mode on your interfaces. # ifconfig ix0 promisc # ifconfig ix1 promisc This is an additional requirement when using netmap bridge, because that is not done automatically (differently from what happens with if_bridge(4)). If promisc is not enabled, the NIC will drop any unicast packet that is not directed to the NIC's address (e.g. the ARP reply in your case). Broadcast packets will of course pass (e.g. the ARP request). This explains the absence of IRQs and the head/tail pointers not being updated. So no bugs AFAIK. I figured it out the hard way, but it was actually also documented on the github (https://github.com/luigirizzo/netmap#receiver-does-not-receive). I will add it to the netmap bridge man page. Cheers, Vincenzo Il giorno sab 21 nov 2020 alle ore 17:06 Vincenzo Maffione < vmaffione@freebsd.org> ha scritto: > > > Il giorno ven 20 nov 2020 alle ore 14:31 Rajesh Kumar > ha scritto: > >> Hi Vincenzo, >> >> On Fri, Nov 20, 2020 at 3:20 AM Vincenzo Maffione >> wrote: >> >>> >>> Ok, now it makes sense. Thanks for clarifying. I see that if_axp(4) uses >>> iflib(4). This means that actually if_axp(4) has native netmap support, >>> because iflib(4) has native netmap support. >>> >>> >> It means that the driver has some modifications to allow netmap to >>> directly program the NIC rings. These modifications are mostly the >>> per-driver txsync and rxsyng routines. >>> In case of iflib(4) drivers, these modifications are provided directly >>> within the iflib(4) code, and therefore any driver using iflib will have >>> native netmap support. >>> >> >> Thanks for clarifying on the Native Netmap support. >> >> Ok, this makes sense, because also ix(4) uses iflib, and therefore you >>> are basically hitting the same issue of if_axp(4) >>> At this point I must think that there is still some issue with the >>> interaction between iflib(4) and netmap(4). >>> >> >> Ok. Let me know if any more debug info needed in this part. >> >> I see. This info may be useful. Have you tried to look at interrupts >>> (e.g. `vmstat -i`), to see if "ix0" gets any RX interrupts (for the missing >>> ARP replies)? >>> >> >> It's interesting here. When I try with Intel NIC card. I see atleast 1 >> interrupt raised. But not sure whether that is for ARP reply. Because, >> when I try to dump the packet from "bridge"(modified) utility, I don't see >> any ARP reply packet getting dumped. >> >> >> *irq59: ix0:rxq0 1 0 (only 1 interrupt on >> the opposite side)*irq67: ix0:aq 2 0 >> >> *irq68: ix1:rxq0 3 0 (you can see 3 >> interrupts for 3 ARP requests from System 1)*irq76: ix1:aq >> 2 0 >> >> The same experiment, when I try with AMD inbuilt ports, I don't see that >> 1 interrupt also raised. >> >> irq81: ax0:dev_irq 16 0 >> irq83: ax0 2541 4 >> irq93: ax1:dev_irq 27 0 >> irq95: ax1 2371 3 >> *irq97: ax1:rxq0 3 0 (you can see 3 >> interrupts for 3 ARP requests from System 1, but no interrupt is seen from >> "ax0:rxq0" for ARP reply from System 2)* >> >> I will do some more testing to see whether this behavior is consistent or >> intermittent. >> >> Also the igb(4) driver is using iflib(4). So the involved netmap code is >>> the same as ix(4) and if_axp(4). >>> This is something that I'm not able to understand right now. >>> It does not look like something related to offloads. >>> >>> Next week I will try to see if I can reproduce your issue with em(4), >>> and report back. That's still an Intel driver using iflib(4). >>> >> >> The "igb(4)" driver, with which things are working now is related to >> em(4) driver (may be for newer hardware version). Initially we faced >> similar issue with igb(4) driver as well. After reverting the following >> commits, things started to work. Thanks to Stephan Dewt (copied) for >> pointing this. But it still fails with ix(4) driver and if_axp(4) driver. >> >> >> https://github.com/freebsd/freebsd/commit/e12efc2c9e434075d0740e2e2e9e2fca2ad5f7cf >> >> Thanks for providing your inputs on this issue Vincenzo. Let me know for >> any more details that you need. >> >> > I was able to reproduce your issue on FreeBSD-CURRENT running within a > QEMU VM, with two em(4) devices and the netmap bridge running between them. > I see the ARP request packet received on em0 (with associated IRQ), and > forwarded on em1. However, the ARP reply coming on em1 does not trigger an > IRQ on em1, and indeed the NIC RX head/tail pointers are not incremented as > they should (`sysctl -a | grep em.1 | grep queue_rx`) ... that is weird, > and lets me think that the issue is more likely driver-related than > netmap/iflib-related. > In any case, would you mind filing the issue on the bugzilla, so that we > can properly track this issue? > > Thanks, > Vincenzo > > >> Thanks, >> Rajesh. >> >