From nobody Mon Oct 18 04:46:03 2021 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D95B4181666E; Mon, 18 Oct 2021 04:46:16 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (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 4HXkpv1hxcz3ntR; Mon, 18 Oct 2021 04:46:15 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: by mail-ua1-x92e.google.com with SMTP id i22so1544058ual.10; Sun, 17 Oct 2021 21:46:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=oQwR1gd5Pwp63SjqlpIBKt8Vq3vDc6AF07wH5CLMutQ=; b=AAYdcvQlxPjzV89pxAZYR7SJatpL+cvOlFUteT8GSDXa+w5R9rJ12P3Aw6SXVx3fji e2Z35e0I/x2d4G0IOfkruB+SUtrVmx4ELE2mo7d25pT3Jm9AS80Wgv4WeNVTHDXLcmVQ UUjVuhft67UualNLRDkHHi0v/m0x/JiznMOX/z/Oyr+yfX7I4ZA142PFMTB+YF9MekMp CjR2Q6dIXA6sOaF2Ml5VwQsK+PmrxriTUDwCZq0VlLk8fwOVuC0he8HEDTXBPjurd11d XBHMqU862pJ/jTzkwjdx5SL0Od8mxxVAFm/ZIZOV58hmZ3CsZx8OsW7RJ8LQbWki8uy+ AeBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=oQwR1gd5Pwp63SjqlpIBKt8Vq3vDc6AF07wH5CLMutQ=; b=GFwXyhiZyDhb4jsZTYYn3OAUUgoPrGKbG1R58z4KrEu9RLhsq+MPCNsF3kJBZeV8Jn h8HVimRzgxn+qbGGMpIDutYME1TWNPLg98fpp1Ze0GfMB0civ6RitSuRrBe0DflHD7HX vU5xaAujWVh4zWIc/5t06L2Ijuwb30fG+GirW/bgWA2a4Sz9CX3sgDJrFdc1F3rt6Rsa IN8PLP8eOtbChnJiMjsap9pp6qXL694BM2p3bVrzaVL9muXs40iWpgTDT+/QTzmkcPIW 3WuW8va3nz+Ov9k/HaS+1uuASRDmi7Rd//kKAKTuV8d8XxBLteWk+KtNUdWpH0dXE/go jLZg== X-Gm-Message-State: AOAM532UR7HNOLN5vwuLCFSQonP6PIDSGAeSyvXbbbIP1DmnvgUhoDL7 jgAeIB6FrWeu+qdePYpBGfLgWcEszELiM2VXSoGiW+GvWqc= X-Google-Smtp-Source: ABdhPJxqlUl7KGpDDj6WJaov04gNH/XfY0/KS8bkKHK20b+auHwpfBaOpKm5tRzSX0xZxTXiV7VKEFJRWZVdUr8XxDE= X-Received: by 2002:a67:c903:: with SMTP id w3mr25524083vsk.6.1634532374069; Sun, 17 Oct 2021 21:46:14 -0700 (PDT) List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 From: =?UTF-8?B?w5Z6a2FuIEtJUklL?= Date: Mon, 18 Oct 2021 07:46:03 +0300 Message-ID: Subject: Iterating all VNETs from userspace application To: FreeBSD Net , freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4HXkpv1hxcz3ntR X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=AAYdcvQl; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of ozkankirik@gmail.com designates 2607:f8b0:4864:20::92e as permitted sender) smtp.mailfrom=ozkankirik@gmail.com X-Spamd-Result: default: False [0.61 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_SPAM_SHORT(0.98)[0.980]; 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::92e:from]; NEURAL_SPAM_LONG(1.00)[1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; R_MIXED_CHARSET(0.62)[subject]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Hi, I'm trying to gather all even within jails/vnet interface stats which interface type ifmd_data.ifi_type == IFT_ETHER (6) for bsnmpd. Related function (not modified) is here: https://github.com/freebsd/freebsd-src/blob/main/contrib/bsnmp/snmp_mibII/mibII.c#L926-L985 It's possible to add a filter interface type adding a line below line 961: if (mib.ifmd_data.ifi_type != IFT_ETHER) return; I'm looking for a way to iterate VNET instances, but net/vnet.h is only for kernel space. VNET_LIST_RLOCK_NOSLEEP(); VNET_FOREACH(vnet_iter) { CURVNET_SET(vnet_iter); mib_refresh_iflist(); CURVNET_RESTORE(); } VNET_LIST_RUNLOCK_NOSLEEP(); The code above not working in userspace. Also I wonder that if it's possible to switch between jails. The pseudo code I want to write: JAIL_FOREACH(jail_iter) { jail_attach(jail_iter); mib_refresh_iflist(); jail_detach(); } What is the right way to gather all interface stats ? Have a nice day Regards From nobody Mon Oct 18 07:49:40 2021 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5242517F24C6; Mon, 18 Oct 2021 07:49:53 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:13b:39f::9f:25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HXptn1Bfmz3MpF; Mon, 18 Oct 2021 07:49:52 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 1EA198D4A212; Mon, 18 Oct 2021 07:49:45 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 32384E707CB; Mon, 18 Oct 2021 07:49:44 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id 53X6n4w7OZmX; Mon, 18 Oct 2021 07:49:41 +0000 (UTC) Received: from [169.254.86.56] (unknown [IPv6:fde9:577b:c1a9:4902:958c:feeb:258b:6e9f]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id C130BE707AC; Mon, 18 Oct 2021 07:49:41 +0000 (UTC) From: "Bjoern A. Zeeb" To: "=?utf-8?q?=C3=96zkan?= KIRIK" Cc: "FreeBSD Net" , freebsd-hackers@freebsd.org Subject: Re: Iterating all VNETs from userspace application Date: Mon, 18 Oct 2021 07:49:40 +0000 X-Mailer: MailMate (2.0BETAr6151) Message-ID: In-Reply-To: References: List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4HXptn1Bfmz3MpF X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On 18 Oct 2021, at 4:46, =C3=96zkan KIRIK wrote: > Hi, > > I'm trying to gather all even within jails/vnet interface stats which > interface type ifmd_data.ifi_type =3D=3D IFT_ETHER (6) for bsnmpd. Rela= ted > function (not modified) is here: > > https://github.com/freebsd/freebsd-src/blob/main/contrib/bsnmp/snmp_mib= II/mibII.c#L926-L985 > > It's possible to add a filter interface type adding a line below line = > 961: > if (mib.ifmd_data.ifi_type !=3D IFT_ETHER) return; > > I'm looking for a way to iterate VNET instances, but net/vnet.h is > only for kernel space. > VNET_LIST_RLOCK_NOSLEEP(); > VNET_FOREACH(vnet_iter) { > CURVNET_SET(vnet_iter); > mib_refresh_iflist(); > CURVNET_RESTORE(); > } > VNET_LIST_RUNLOCK_NOSLEEP(); > The code above not working in userspace. > > Also I wonder that if it's possible to switch between jails. The > pseudo code I want to write: > > JAIL_FOREACH(jail_iter) { > jail_attach(jail_iter); > mib_refresh_iflist(); > jail_detach(); > } > > What is the right way to gather all interface stats ? Have a look at libkvm; I seem to remember adding vnet support. /bz From nobody Mon Oct 18 08:07:26 2021 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3019A17FB9FC; Mon, 18 Oct 2021 08:07:37 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: from mail-ua1-x92b.google.com (mail-ua1-x92b.google.com [IPv6:2607:f8b0:4864:20::92b]) (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 4HXqHF0PXFz3k1m; Mon, 18 Oct 2021 08:07:37 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: by mail-ua1-x92b.google.com with SMTP id a17so455633uax.12; Mon, 18 Oct 2021 01:07:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=o+9bC1vJ4pWPjp4SoIypU5RojCMPw7I3dlDYUjc6ceU=; b=nzF/LKLAuuRut7B82cqStez1t9SwnA9POKJThA24FKruFARD6jSP7Dd0Re8Oog9N8k dwl5QRdTfCk4tJ8+ejur5+fitSPfRVKxQ1vuhjGTd7iUQq9GiRPuhyh20Jwdk+h2MRTI 2mt/cpJ4N+PccXareqNco1+BlkeE1XYvq7EWN7aNjUo2nNpXAzk81o2MJPSP/gH8kC8/ HQEREzzTIv+3Jw/ZBIdGNxIZ+sXGErRPQ27cXFHInT0cAHotz9YSVTxVazN25cVf7qIV wtJkRW62UomjK9XaohB3TV0R6yEUpSSYHHhArPPgudk/33IFShYyg6IZjatDAfSIYqt6 898w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=o+9bC1vJ4pWPjp4SoIypU5RojCMPw7I3dlDYUjc6ceU=; b=zEgOO96WtQAGbQKs0O6BjTa2j0k8aMUf8dVg/5lLP2YEQKEsKAsAFe5qjuFx6AjaTC EDOpljyfOdhVP3WkZ2uY61ACG+SnPyKiIpCEJfkhRnucvp23htXtDfNt1zb51YZFJ+At SujXSihbflPIZgnuNxousxOHQv5bMP0Qhg6u4nnHPfPwaXYMXbJUSBf6zzVaXG8R6yqI 44YaduGPTqLtTKFgM289SWVqqdud7/lAtV2rnMo17HSEDGtG7spaYynf3Hof1G1Tu7wF D6vr4bFlxLFm0cm0UZGurV0BVy46a6SxTf3cqbvSuMPoQ0MJPShaoban1wf9bZmig7t4 BJcQ== X-Gm-Message-State: AOAM531ST/i4nwCx6fhZG8TFf8BErNqD5TQaRQDWwOXHW83H3deDN2HF pj0y+j0U5vO7yPM5aV01+4MwxbvA6qHdD7Le58kaaIze X-Google-Smtp-Source: ABdhPJwwh61c86PxDXo+wrwwGiHwfCRjEneP6rnqFsrYoHa0ErUuMhd3g5hMDvHS2tgUQbhbmuj0SeuB4BDxz8h/UI4= X-Received: by 2002:a67:c903:: with SMTP id w3mr25877100vsk.6.1634544456691; Mon, 18 Oct 2021 01:07:36 -0700 (PDT) List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?B?w5Z6a2FuIEtJUklL?= Date: Mon, 18 Oct 2021 11:07:26 +0300 Message-ID: Subject: Re: Iterating all VNETs from userspace application To: "Bjoern A. Zeeb" Cc: FreeBSD Net , freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4HXqHF0PXFz3k1m X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Thank you Bjoern, I'll have al On Mon, Oct 18, 2021 at 10:49 AM Bjoern A. Zeeb wrote: > > On 18 Oct 2021, at 4:46, =C3=96zkan KIRIK wrote: > > > Hi, > > > > I'm trying to gather all even within jails/vnet interface stats which > > interface type ifmd_data.ifi_type =3D=3D IFT_ETHER (6) for bsnmpd. Rela= ted > > function (not modified) is here: > > > > https://github.com/freebsd/freebsd-src/blob/main/contrib/bsnmp/snmp_mib= II/mibII.c#L926-L985 > > > > It's possible to add a filter interface type adding a line below line > > 961: > > if (mib.ifmd_data.ifi_type !=3D IFT_ETHER) return; > > > > I'm looking for a way to iterate VNET instances, but net/vnet.h is > > only for kernel space. > > VNET_LIST_RLOCK_NOSLEEP(); > > VNET_FOREACH(vnet_iter) { > > CURVNET_SET(vnet_iter); > > mib_refresh_iflist(); > > CURVNET_RESTORE(); > > } > > VNET_LIST_RUNLOCK_NOSLEEP(); > > The code above not working in userspace. > > > > Also I wonder that if it's possible to switch between jails. The > > pseudo code I want to write: > > > > JAIL_FOREACH(jail_iter) { > > jail_attach(jail_iter); > > mib_refresh_iflist(); > > jail_detach(); > > } > > > > What is the right way to gather all interface stats ? > > Have a look at libkvm; I seem to remember adding vnet support. > > /bz > From nobody Mon Oct 18 08:07:55 2021 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id EC58C17FBFF0; Mon, 18 Oct 2021 08:08:06 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) (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 4HXqHp5pblz3kRT; Mon, 18 Oct 2021 08:08:06 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: by mail-ua1-x931.google.com with SMTP id i15so3410770uap.0; Mon, 18 Oct 2021 01:08:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=+Y+u4tfmgNFW7nNLaMVLXf8DajQkM6LGHBWLAFRXXXQ=; b=CeSO5yoK3SMAwMOWcExp8nc8mzlwtYh+Ps07dtvxBRh67TuU38jmSevImedkPq+B0j CPvvSlWkvYqegRikRhZXbp31Q8T4osEJ+QSP8QsU62epSxGqqz73uQ+p+ICF+DSQmlff ZUYyL7nRJ50QgVcirsuXaXGiE3XT3mquTPNfkDcyd/p3/ae8ayN9uV/PL2u+ndVbcK4R qO+noSQYUfinLe76jfBdy9moRNLq4jFeOEXE0AtcQcx55SBbKrdyzy4eMRKdlunx5IHH ncVljNuBnB97Fhg6sDuHN0sONhv+AVUE1q39vuBSxtR5IZe0Hz4a8oyVeDO4CqhXAyey It6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=+Y+u4tfmgNFW7nNLaMVLXf8DajQkM6LGHBWLAFRXXXQ=; b=tR7Ywl6VkGIjovBP+83xBHT1yM/vLt3pYjkWJxncI4bmfK8anlWLh28RaXZ2/0P7F4 Lr9OhRxWeAgbuawClZukaTx735HrLtAwp7i78kB3Jw96v46yBEseTOUoLjImiYCZoBOa L92sOVtu3xmMp6WAtxdVOOX+tNK6ZNMIHDqYt33z/AXYG5kPCcXRuQLUZOg+N4ScWuI5 3U3SAELp+ESZ1/6UNhCILTErk4ANusNUg88CbRX9M/6RgBTdIhKh4B6CjZIhzm02/smN I2xsQdjArXvnNOKrxGkjKLSGfTEUUXgm/W4vxnwZLEbMZ+U1GJx6dYjMhYskvxT1++Oc XffA== X-Gm-Message-State: AOAM532hx1P59FvejE245VhkHLPg1jJTXEJkb8TTncO6fGlzJ5RC2W7A O+pTvZpUtMKoKV81ahfkQQh61dLWqE64NmEXREN1zAVQAOU= X-Google-Smtp-Source: ABdhPJxp18gSFmQzfvRsDIGorcRLjFGGn/u3aowlKT77T1+ApI+O0k1yHjsVPR/sr/idgkR8Kcj3nDiMdlUgsjgCbUc= X-Received: by 2002:a05:6102:cd2:: with SMTP id g18mr25325555vst.25.1634544486330; Mon, 18 Oct 2021 01:08:06 -0700 (PDT) List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?B?w5Z6a2FuIEtJUklL?= Date: Mon, 18 Oct 2021 11:07:55 +0300 Message-ID: Subject: Re: Iterating all VNETs from userspace application To: "Bjoern A. Zeeb" Cc: FreeBSD Net , freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4HXqHp5pblz3kRT X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_FROM(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N I'll have a look On Mon, Oct 18, 2021 at 11:07 AM =C3=96zkan KIRIK w= rote: > > Thank you Bjoern, I'll have al > > On Mon, Oct 18, 2021 at 10:49 AM Bjoern A. Zeeb > wrote: > > > > On 18 Oct 2021, at 4:46, =C3=96zkan KIRIK wrote: > > > > > Hi, > > > > > > I'm trying to gather all even within jails/vnet interface stats which > > > interface type ifmd_data.ifi_type =3D=3D IFT_ETHER (6) for bsnmpd. Re= lated > > > function (not modified) is here: > > > > > > https://github.com/freebsd/freebsd-src/blob/main/contrib/bsnmp/snmp_m= ibII/mibII.c#L926-L985 > > > > > > It's possible to add a filter interface type adding a line below line > > > 961: > > > if (mib.ifmd_data.ifi_type !=3D IFT_ETHER) return; > > > > > > I'm looking for a way to iterate VNET instances, but net/vnet.h is > > > only for kernel space. > > > VNET_LIST_RLOCK_NOSLEEP(); > > > VNET_FOREACH(vnet_iter) { > > > CURVNET_SET(vnet_iter); > > > mib_refresh_iflist(); > > > CURVNET_RESTORE(); > > > } > > > VNET_LIST_RUNLOCK_NOSLEEP(); > > > The code above not working in userspace. > > > > > > Also I wonder that if it's possible to switch between jails. The > > > pseudo code I want to write: > > > > > > JAIL_FOREACH(jail_iter) { > > > jail_attach(jail_iter); > > > mib_refresh_iflist(); > > > jail_detach(); > > > } > > > > > > What is the right way to gather all interface stats ? > > > > Have a look at libkvm; I seem to remember adding vnet support. > > > > /bz > > From nobody Mon Oct 18 10:48:18 2021 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1FDF217F6C1E for ; Mon, 18 Oct 2021 10:48:22 +0000 (UTC) (envelope-from avg@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 "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HXtrk0StVz3FYl for ; Mon, 18 Oct 2021 10:48:22 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from [192.168.0.88] (unknown [195.64.148.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id A51A62037D for ; Mon, 18 Oct 2021 10:48:21 +0000 (UTC) (envelope-from avg@FreeBSD.org) To: "net@FreeBSD.org" From: Andriy Gapon Subject: NULL pointer crash in iflib_rxd_pkt_get with vmxnet3 Message-ID: <8ff3f608-b66d-698d-027c-1965b366794a@FreeBSD.org> Date: Mon, 18 Oct 2021 13:48:18 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.14.0 List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-ThisMailContainsUnwantedMimeParts: N This happened on FreeBSD 12.2 running as an ESXi guest with vmxnet3 network interface. Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff809d4bad stack pointer = 0x28:0xfffffe00c85cba40 frame pointer = 0x28:0xfffffe00c85cba40 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (if_io_tqg_0) trap number = 12 panic: page fault (kgdb) bt #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 #1 doadump (textdump=-933448896) at /usr/src/sys/kern/kern_shutdown.c:447 #2 0xffffffff8038f1cc in db_fncall_generic (addr=, nargs=0, args=, rv=) at /usr/src/sys/ddb/db_command.c:622 #3 db_fncall (dummy1=, dummy2=, dummy3=, dummy4=) at /usr/src/sys/ddb/db_command.c:670 #4 0xffffffff8038eaf6 in db_command (last_cmdp=, cmd_table=, dopager=0) at /usr/src/sys/ddb/db_command.c:494 #5 0xffffffff80393a68 in db_script_exec (scriptname=, warnifnotfound=) at /usr/src/sys/ddb/db_script.c:304 #6 0xffffffff80393892 in db_script_kdbenter (eventname=) at /usr/src/sys/ddb/db_script.c:326 #7 0xffffffff80391ac3 in db_trap (type=, code=) at /usr/src/sys/ddb/db_main.c:251 #8 0xffffffff807821e2 in kdb_trap (type=3, code=0, tf=0xfffffe00c85cb630) at /usr/src/sys/kern/subr_kdb.c:700 #9 0xffffffff809d870e in trap (frame=0xfffffe00c85cb630) at /usr/src/sys/amd64/amd64/trap.c:583 #10 #11 kdb_enter (why=0xffffffff80b17af9 "panic", msg=0xffffffff80b17af9 "panic") at /usr/src/sys/kern/subr_kdb.c:486 #12 0xffffffff8073ddce in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:975 #13 0xffffffff8073dc23 in panic (fmt=0xffffffff81178120 "") at /usr/src/sys/kern/kern_shutdown.c:909 #14 0xffffffff809d8b31 in trap_fatal (frame=0xfffffe00c85cb980, eva=0) at /usr/src/sys/amd64/amd64/trap.c:921 #15 0xffffffff809d8b8f in trap_pfault (frame=0xfffffe00c85cb980, usermode=, signo=, ucode=) at /usr/src/sys/amd64/amd64/trap.c:739 #16 0xffffffff809d8256 in trap (frame=0xfffffe00c85cb980) at /usr/src/sys/amd64/amd64/trap.c:405 #17 #18 memcpy_erms () at /usr/src/sys/amd64/amd64/support.S:577 #19 0xffffffff8084d049 in iflib_rxd_pkt_get (rxq=0xfffffe00ea9f5000, ri=) at /usr/src/sys/net/iflib.c:2737 #20 iflib_rxeof (rxq=, budget=) at /usr/src/sys/net/iflib.c:2879 #21 _task_fn_rx (context=) at /usr/src/sys/net/iflib.c:3868 #22 0xffffffff807808bd in gtaskqueue_run_locked (queue=0xfffff800020c7200) at /usr/src/sys/kern/subr_gtaskqueue.c:362 #23 0xffffffff8078068e in gtaskqueue_thread_loop (arg=) at /usr/src/sys/kern/subr_gtaskqueue.c:537 #24 0xffffffff8070792d in fork_exit (callout=0xffffffff80780610 , arg=0xfffffe00007f8008, frame=0xfffffe00c85cbc00) at /usr/src/sys/kern/kern_fork.c:1088 #25 (kgdb) fr 19 #19 0xffffffff8084d049 in iflib_rxd_pkt_get (rxq=0xfffffe00ea9f5000, ri=) at /usr/src/sys/net/iflib.c:2737 2737 /usr/src/sys/net/iflib.c: No such file or directory. (kgdb) i loc sd = {ifsd_cl = 0xfffff80002d61a38, ifsd_m = 0xfffff80002d62a38, ifsd_fl = 0xfffff80002d93400} m = 0xfffff80123211c00 (kgdb) p m->m_data $1 = (caddr_t) 0xfffff80123211c58 "" (kgdb) p sd.ifsd_cl $2 = (caddr_t *) 0xfffff80002d61a38 (kgdb) p *sd.ifsd_cl $3 = (caddr_t) 0x0 Is this a known issue? Is there a chance that this has already been fixed? Thank you. -- Andriy Gapon From nobody Mon Oct 18 18:19:36 2021 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 161F0180CA9B for ; Mon, 18 Oct 2021 18:19:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HY4sP04zTz3mvx for ; Mon, 18 Oct 2021 18:19:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id D5EE52517E for ; Mon, 18 Oct 2021 18:19:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 19IIJa4e079099 for ; Mon, 18 Oct 2021 18:19:36 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 19IIJaZO079098 for net@FreeBSD.org; Mon, 18 Oct 2021 18:19:36 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 232451] [igb] I210 NIC can not send more than ~670Mbit/s with flow control enabled. Date: Mon, 18 Oct 2021 18:19:36 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.2-STABLE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: lev@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D232451 --- Comment #5 from Lev A. Serebryakov --- Looks like latest stable12 doesn't have this problem. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Mon Oct 18 18:31:14 2021 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8E1DB1811BC8 for ; Mon, 18 Oct 2021 18:31:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HY56p3Y5Vz3qxS for ; Mon, 18 Oct 2021 18:31:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 572FD254CD for ; Mon, 18 Oct 2021 18:31:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 19IIVELp086744 for ; Mon, 18 Oct 2021 18:31:14 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 19IIVEJT086735 for net@FreeBSD.org; Mon, 18 Oct 2021 18:31:14 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 232451] [igb] I210 NIC can not send more than ~670Mbit/s with flow control enabled. Date: Mon, 18 Oct 2021 18:31:14 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.2-STABLE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: kbowling@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D232451 Kevin Bowling changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|New |Closed --- Comment #6 from Kevin Bowling --- Thanks Lev! I can confirm the driver is in a similar state in stable/13 and main, and this version will ship in 12.3 so I will close this bug out. I am not sure on the specific fix, a lot of things have been improved since the initial report. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Mon Oct 18 21:35:49 2021 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E188D17FCC41 for ; Mon, 18 Oct 2021 21:35:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HY9Cn5z9Gz4Vr0 for ; Mon, 18 Oct 2021 21:35:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id AE33327E47 for ; Mon, 18 Oct 2021 21:35:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 19ILZnbn088495 for ; Mon, 18 Oct 2021 21:35:49 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 19ILZnws088494 for net@FreeBSD.org; Mon, 18 Oct 2021 21:35:49 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 211062] [ixv] sr-iov virtual function driver fails to attach Date: Mon, 18 Oct 2021 21:35:49 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: IntelNetworking, needs-patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: j@iamplugged.in X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211062 xygzen changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |j@iamplugged.in --- Comment #15 from xygzen --- If it helps any - I was getting the exact same issue at one cloud provider. When I enabled SR-IOV in the BIOS it had a cryptic message about needing to enable ASPM (Active State Power Management) for the SR-IOV to work properly. Nothing I did allowed it to work. When I switched providers, there was an ASPM setting in the BIOS of the new machine that wasn't there previously - and these were both Supermicro board= s so it looks like not all motherboards support this functionality or maybe ther= e is a newer version of the BIOS that has the setting correctly enabled. I still needed to enable hw.pci.honor_msi_blacklist=3D0 in /boot/loader.con= f and used the latest IX and IXV drivers from Intel: IX - v3.3.25 - https://www.intel.com/content/www/us/en/download/14303/intel-network-adapte= rs-driver-for-pcie-10-gigabit-network-connections-under-freebsd.html IXV -v.1.5.28 - https://www.intel.com/content/www/us/en/download/645984/intel-network-adapt= er-virtual-function-driver-for-pcie-10-gigabit-network-connections-under-fr= eebsd.html Once I ran iovctl -C -f /etc/iovctl.conf the VF driver correctly attached to ixv0 (no passthrough) and the pci devices were configured correctly for the ixv1-3 for passthrough without drivers attached. Setting iovctl_files=3D"/etc/iovctl.conf" in rc.conf and changing the ip to= be configured on ixv0 instead of ix0 got this up and running automatically on reboot. If you're looking for a good cloud host with support for this I can highly recommend https://www.zare.com Hope that helps! --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Tue Oct 19 14:47:40 2021 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4245217FCD81 for ; Tue, 19 Oct 2021 14:47:48 +0000 (UTC) (envelope-from mike@mail.karels.net) Received: from mail.karels.net (mail.karels.net [216.160.39.52]) by mx1.freebsd.org (Postfix) with ESMTP id 4HYc6V5B7zz3LcQ for ; Tue, 19 Oct 2021 14:47:46 +0000 (UTC) (envelope-from mike@mail.karels.net) Received: from mail.karels.net (localhost [127.0.0.1]) by mail.karels.net (8.16.1/8.16.1) with ESMTPS id 19JElew2005172 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 19 Oct 2021 09:47:40 -0500 (CDT) (envelope-from mike@mail.karels.net) Received: (from mike@localhost) by mail.karels.net (8.16.1/8.16.1/Submit) id 19JElejZ005171; Tue, 19 Oct 2021 09:47:40 -0500 (CDT) (envelope-from mike) Message-Id: <202110191447.19JElejZ005171@mail.karels.net> To: freebsd-net@freebsd.org From: Mike Karels Reply-to: karels@FreeBSD.org Subject: cleaning up INET: deprecating network class A/B/C List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5169.1634654860.1@mail.karels.net> Date: Tue, 19 Oct 2021 09:47:40 -0500 X-Rspamd-Queue-Id: 4HYc6V5B7zz3LcQ X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of mike@mail.karels.net has no SPF policy when checking 216.160.39.52) smtp.mailfrom=mike@mail.karels.net X-Spamd-Result: default: False [2.29 / 15.00]; HAS_REPLYTO(0.00)[karels@FreeBSD.org]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[mike]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; REPLYTO_ADDR_EQ_FROM(0.00)[]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; TO_DN_NONE(0.00)[]; NEURAL_SPAM_SHORT(0.99)[0.992]; DMARC_NA(0.00)[FreeBSD.org]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[karels@FreeBSD.org,mike@mail.karels.net]; RCVD_NO_TLS_LAST(0.10)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:209, ipnet:216.160.36.0/22, country:US]; FROM_NEQ_ENVFROM(0.00)[karels@FreeBSD.org,mike@mail.karels.net]; TO_DOM_EQ_FROM_DOM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N I plan to do some cleanup of the residual code defining and using the old Internet network classes (A/B/C), which have been obsolete since CIDR took hold. This is an outline of what I plan, as it will happen in a number of steps and reviews, and I would like feedback on some of it. I want to reduce the use of the obsolete definitions and interfaces, and make it less likely for them to be used going forward. I plan to hide the Class A/B/C bit definitions unless a feature test macro is defined; that will be the default for user code for the moment. A few files in the kernel will need to define the feature test macro for now (but see the next two paragraphs). Several of the uses of the historical network class macros have to do with generating a default network mask when none is provided. The worst of these is in the code for SIOCAIFADDR (add interface address). I want to have ifconfig and/or the kernel warn about this; the default is most likely wrong. After some time with a warning, it should become an error to set an Internet interface address without a mask (except for loopback and point-to-point interfaces, where the mask is meaningless). I am tempted to define a new default mask, e.g. 24 bits, for those places that must be able to generate one. An example is NFS BOOTP code. I am interested in feedback on this idea. It would help to reduce use of the old masks, and 8- or 16-bit prefixes are highly unlikely to be correct. Comments on adding a default mask? This would eliminate the use of the old class macros in the kernel. The C library routines inet_netof() and inet_lnaof() should be deprecated, as they use the historical masks. inet_makeaddr() is almost as bad; it works almost by accident as long as a mask is a multiple of 8 bits. I'd like to remove their use from the base system. Unfortunately, I have no idea how much other software uses them. We can at least document them as deprecated and unsafe. Mike From nobody Tue Oct 19 15:57:00 2021 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8CF0917F4747 for ; Tue, 19 Oct 2021 15:57:11 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HYdfX15ZHz4SDC; Tue, 19 Oct 2021 15:57:07 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 19JFv0sS063588; Tue, 19 Oct 2021 08:57:00 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 19JFv0cW063587; Tue, 19 Oct 2021 08:57:00 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202110191557.19JFv0cW063587@gndrsh.dnsmgr.net> Subject: Re: cleaning up INET: deprecating network class A/B/C In-Reply-To: <202110191447.19JElejZ005171@mail.karels.net> To: karels@FreeBSD.org Date: Tue, 19 Oct 2021 08:57:00 -0700 (PDT) CC: freebsd-net@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 4HYdfX15ZHz4SDC X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N > I plan to do some cleanup of the residual code defining and using the > old Internet network classes (A/B/C), which have been obsolete since > CIDR took hold. This is an outline of what I plan, as it will happen > in a number of steps and reviews, and I would like feedback on some > of it. > > I want to reduce the use of the obsolete definitions and interfaces, > and make it less likely for them to be used going forward. I plan > to hide the Class A/B/C bit definitions unless a feature test macro > is defined; that will be the default for user code for the moment. > A few files in the kernel will need to define the feature test macro > for now (but see the next two paragraphs). Sounds good. > > Several of the uses of the historical network class macros have to > do with generating a default network mask when none is provided. > The worst of these is in the code for SIOCAIFADDR (add interface > address). I want to have ifconfig and/or the kernel warn about this; > the default is most likely wrong. After some time with a warning, > it should become an error to set an Internet interface address > without a mask (except for loopback and point-to-point interfaces, > where the mask is meaningless). Sounds good except that last bit, mask on loopback is meaningful, especially for people like me that alrady have modified systems that change loopback from 127/8 to 127/16. Also care should be taken on point to point, I think there is probably a fair bit of code/systems out there that MAY still assume /30 or require /30 to be set on these, it MAY be an interropt issue to force the FreeBSD end to /32. > > I am tempted to define a new default mask, e.g. 24 bits, for those > places that must be able to generate one. An example is NFS BOOTP > code. I am interested in feedback on this idea. It would help to > reduce use of the old masks, and 8- or 16-bit prefixes are highly > unlikely to be correct. Comments on adding a default mask? This > would eliminate the use of the old class macros in the kernel. I am not keen on the idea of a default mask at all. I believe every place that an IP address -is- used also has the ability to specify a netmask. > > The C library routines inet_netof() and inet_lnaof() should be > deprecated, as they use the historical masks. inet_makeaddr() is > almost as bad; it works almost by accident as long as a mask is a > multiple of 8 bits. I'd like to remove their use from the base > system. Unfortunately, I have no idea how much other software uses > them. We can at least document them as deprecated and unsafe. Wrap them in a depricating macro, the do a EXP-RUN with that macro defined, should get a good idea of that fallout from that. I do believe Linux still defines the CLASS macros. > Mike -- Rod Grimes rgrimes@freebsd.org From nobody Tue Oct 19 21:15:54 2021 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0FA361817506 for ; Tue, 19 Oct 2021 21:15:57 +0000 (UTC) (envelope-from mike@mail.karels.net) Received: from mail.karels.net (mail.karels.net [216.160.39.52]) by mx1.freebsd.org (Postfix) with ESMTP id 4HYmkM61Mjz3JTy for ; Tue, 19 Oct 2021 21:15:55 +0000 (UTC) (envelope-from mike@mail.karels.net) Received: from mail.karels.net (localhost [127.0.0.1]) by mail.karels.net (8.16.1/8.16.1) with ESMTPS id 19JLFsPB006626 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 19 Oct 2021 16:15:54 -0500 (CDT) (envelope-from mike@mail.karels.net) Received: (from mike@localhost) by mail.karels.net (8.16.1/8.16.1/Submit) id 19JLFsaR006625; Tue, 19 Oct 2021 16:15:54 -0500 (CDT) (envelope-from mike) Message-Id: <202110192115.19JLFsaR006625@mail.karels.net> To: "Rodney W. Grimes" cc: freebsd-net@FreeBSD.org From: Mike Karels Reply-to: karels@freebsd.org Subject: Re: cleaning up INET: deprecating network class A/B/C In-reply-to: Your message of Tue, 19 Oct 2021 08:57:00 -0700. <202110191557.19JFv0cW063587@gndrsh.dnsmgr.net> List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <6623.1634678154.1@mail.karels.net> Date: Tue, 19 Oct 2021 16:15:54 -0500 X-Rspamd-Queue-Id: 4HYmkM61Mjz3JTy X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of mike@mail.karels.net has no SPF policy when checking 216.160.39.52) smtp.mailfrom=mike@mail.karels.net X-Spamd-Result: default: False [-1.37 / 15.00]; HAS_REPLYTO(0.00)[karels@freebsd.org]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[mike]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.70)[-0.704]; NEURAL_HAM_LONG(-1.00)[-0.999]; MIME_GOOD(-0.10)[text/plain]; REPLYTO_ADDR_EQ_FROM(0.00)[]; DMARC_NA(0.00)[freebsd.org]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.97)[-0.968]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[karels@freebsd.org,mike@mail.karels.net]; RCVD_NO_TLS_LAST(0.10)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:209, ipnet:216.160.36.0/22, country:US]; FROM_NEQ_ENVFROM(0.00)[karels@freebsd.org,mike@mail.karels.net]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Rod wrote: > > I plan to do some cleanup of the residual code defining and using the > > old Internet network classes (A/B/C), which have been obsolete since > > CIDR took hold. This is an outline of what I plan, as it will happen > > in a number of steps and reviews, and I would like feedback on some > > of it. > > > > I want to reduce the use of the obsolete definitions and interfaces, > > and make it less likely for them to be used going forward. I plan > > to hide the Class A/B/C bit definitions unless a feature test macro > > is defined; that will be the default for user code for the moment. > > A few files in the kernel will need to define the feature test macro > > for now (but see the next two paragraphs). > Sounds good. > > > > Several of the uses of the historical network class macros have to > > do with generating a default network mask when none is provided. > > The worst of these is in the code for SIOCAIFADDR (add interface > > address). I want to have ifconfig and/or the kernel warn about this; > > the default is most likely wrong. After some time with a warning, > > it should become an error to set an Internet interface address > > without a mask (except for loopback and point-to-point interfaces, > > where the mask is meaningless). > Sounds good except that last bit, mask on loopback is > meaningful, especially for people like me that alrady > have modified systems that change loopback from 127/8 > to 127/16. I'm not aware of anything that uses the mask on a loopback interface; are you? There is no network route installed when the loopback address is set. I think it's similar for point-to-point interfaces, where only the host route for the destination is added. > Also care should be taken on point to point, > I think there is probably a fair bit of code/systems > out there that MAY still assume /30 or require /30 to > be set on these, it MAY be an interropt issue to force > the FreeBSD end to /32. Where is the mask ever used on a point-to-point interface? There is no broadcast address. However, my changes wouldn't break anything that isn't already broken. > > I am tempted to define a new default mask, e.g. 24 bits, for those > > places that must be able to generate one. An example is NFS BOOTP > > code. I am interested in feedback on this idea. It would help to > > reduce use of the old masks, and 8- or 16-bit prefixes are highly > > unlikely to be correct. Comments on adding a default mask? This > > would eliminate the use of the old class macros in the kernel. > I am not keen on the idea of a default mask at all. I believe > every place that an IP address -is- used also has the ability > to specify a netmask. The cases that I'm talking about, like the NFS BOOTP code, have two choices: use a default, or fail (to boot, in this case). I'm not talking about adding a default anywhere, just changing it to ignore the "class" of the address. This would also be true when setting a local address with ifconfig, but that would only be temporary until it starts to return an error. > > The C library routines inet_netof() and inet_lnaof() should be > > deprecated, as they use the historical masks. inet_makeaddr() is > > almost as bad; it works almost by accident as long as a mask is a > > multiple of 8 bits. I'd like to remove their use from the base > > system. Unfortunately, I have no idea how much other software uses > > them. We can at least document them as deprecated and unsafe. > Wrap them in a depricating macro, the do a EXP-RUN with that macro > defined, should get a good idea of that fallout from that. EXP-RUN? > I do believe Linux still defines the CLASS macros. It does. There are a surprising number of references even in base. Mike From nobody Tue Oct 19 23:14:55 2021 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 522E817F432B for ; Tue, 19 Oct 2021 23:14:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HYqMg1qDHz4Z1q for ; Tue, 19 Oct 2021 23:14:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 1F09C1CD2F for ; Tue, 19 Oct 2021 23:14:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 19JNEtSs055237 for ; Tue, 19 Oct 2021 23:14:55 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 19JNEtYY055236 for net@FreeBSD.org; Tue, 19 Oct 2021 23:14:55 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 211062] [ixv] sr-iov virtual function driver fails to attach Date: Tue, 19 Oct 2021 23:14:55 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: IntelNetworking, needs-patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: j@iamplugged.in X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211062 --- Comment #16 from xygzen --- Further update - to get this to work without crashing there is a patch that needs to be applied to Intel VTd in the kernel. A thread on it is here:https://forums.freebsd.org/threads/pci-passthrough-bhyve-usb-xhci.6523= 5/ And the patch is here: https://bz-attachments.freebsd.org/attachment.cgi?id=3D195225 --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Wed Oct 20 02:17:18 2021 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id CC31B180B55F for ; Wed, 20 Oct 2021 02:17:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HYvQ65MYqz4dqb for ; Wed, 20 Oct 2021 02:17:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 94FF11F33B for ; Wed, 20 Oct 2021 02:17:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 19K2HIxH058617 for ; Wed, 20 Oct 2021 02:17:18 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 19K2HIIL058616 for net@FreeBSD.org; Wed, 20 Oct 2021 02:17:18 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 259263] ixgbe flag changing performance problem Date: Wed, 20 Oct 2021 02:17:18 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.2-STABLE X-Bugzilla-Keywords: IntelNetworking X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: kbowling@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D259263 Kevin Bowling changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs@FreeBSD.org |net@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Wed Oct 20 04:02:04 2021 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id F0807180FCD6 for ; Wed, 20 Oct 2021 04:02:22 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.evolve.de (mail.evolve.de [213.239.217.29]) (using TLSv1.3 with cipher TLS_CHACHA20_POLY1305_SHA256 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "mail.evolve.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HYxlL3frRz3NjD; Wed, 20 Oct 2021 04:02:22 +0000 (UTC) (envelope-from freebsd@grem.de) Received: by mail.evolve.de (OpenSMTPD) with ESMTP id a3df2892; Wed, 20 Oct 2021 04:02:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=grem.de; h=content-type :content-transfer-encoding:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; s=20180501; bh=ubkg1y3x1+M9F/ uYPIoMFPXwGWY=; b=oP4QBCex/8/GBzaSwkRo5vJoVODpT5FwTOh/9xjNQOshNK jLYrYpznXCD8OpkGV38xPH54H+B65x+x3Iw8Emn7veqJcxerJ0HR3NmKBRQMyWJg qZvBqO+5JoqDCC2B8Xws0KTYLby4cL9oAmWR+EEDl6eu3E6EuGf0mHP+bxRhjsZ3 5qRPzXAzKle2vf6t2D5CIcz8RCB5ln+UtemhXK501vf28MFyLsu3gXBt0bMPhOId xly/ZUhQXDpid993/35lq+Rj1loF4ANxML4foeqKhjvleANr8IBIkIEgidGOo7Wc VmX6VXe+tSRdnCcc592jcCIVa+FlkKBF82I6IvkA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=grem.de; h=content-type :content-transfer-encoding:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; q=dns; s=20180501; b=ue5n7WK8 IypYY7+OJtqATu37M1wt3UsfcOxFsBicVO4jv+Hy1ZDgVfcX4y3tiadnFJdP2S5h diRMDuZgD03uL22acnDxXa5F7tk8qecjSQfTkNOjaazOGYgvgdDdOK+cUAMQOYLr UrpD0XiIP4yGUKC6LIlfwV47Utyne4XeM/rGKS+R0ZMhK/eFcZCdEzNTyhiUENf7 R3OjWO6MycaJvWM6vFsc23UC6H1ktSebBx2+x+MZ48yOWnTuh0vP0l+vHt3CYt6z ClZw8kvboyw8zQapDRCP32e6JmIQeh7qmAldeqa4Z8MChjWePiQIPW0m/g6kUI/2 dQOa6qHZGgoCag== Received: by mail.evolve.de (OpenSMTPD) with ESMTPSA id 8a3e6c42 (TLSv1.3:AEAD-CHACHA20-POLY1305-SHA256:256:NO); Wed, 20 Oct 2021 04:02:06 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org Mime-Version: 1.0 (1.0) Subject: Re: cleaning up INET: deprecating network class A/B/C From: Michael Gmelin In-Reply-To: <202110192115.19JLFsaR006625@mail.karels.net> Date: Wed, 20 Oct 2021 06:02:04 +0200 Cc: "Rodney W. Grimes" , freebsd-net@freebsd.org Message-Id: <5FF02060-1DA9-4B93-907F-3F608D4B04B7@grem.de> References: <202110192115.19JLFsaR006625@mail.karels.net> To: karels@freebsd.org X-Mailer: iPhone Mail (18F72) X-Rspamd-Queue-Id: 4HYxlL3frRz3NjD X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N > On 19. Oct 2021, at 23:16, Mike Karels wrote: >=20 > =EF=BB=BFRod wrote: >=20 >>> I plan to do some cleanup of the residual code defining and using the >>> old Internet network classes (A/B/C), which have been obsolete since >>> CIDR took hold. This is an outline of what I plan, as it will happen >>> in a number of steps and reviews, and I would like feedback on some >>> of it. >>>=20 >>> I want to reduce the use of the obsolete definitions and interfaces, >>> and make it less likely for them to be used going forward. I plan >>> to hide the Class A/B/C bit definitions unless a feature test macro >>> is defined; that will be the default for user code for the moment. >>> A few files in the kernel will need to define the feature test macro >>> for now (but see the next two paragraphs). >=20 >> Sounds good. >=20 >>>=20 >>> Several of the uses of the historical network class macros have to >>> do with generating a default network mask when none is provided. >>> The worst of these is in the code for SIOCAIFADDR (add interface >>> address). I want to have ifconfig and/or the kernel warn about this; >>> the default is most likely wrong. After some time with a warning, >>> it should become an error to set an Internet interface address >>> without a mask (except for loopback and point-to-point interfaces, >>> where the mask is meaningless). >=20 >> Sounds good except that last bit, mask on loopback is >> meaningful, especially for people like me that alrady >> have modified systems that change loopback from 127/8 >> to 127/16. >=20 > I'm not aware of anything that uses the mask on a loopback interface; > are you? There is no network route installed when the loopback address > is set. I think it's similar for point-to-point interfaces, where only > the host route for the destination is added. >=20 I=E2=80=99ve got a use case that depends on being able to set and read the n= etmask on loopback interfaces consistently to allow orchestration and nomad f= ingerprinters to pick it up. But that=E2=80=99s really only about those oper= ations. Best Michael From nobody Fri Oct 22 14:00:02 2021 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9249C1809CF9; Fri, 22 Oct 2021 14:00:05 +0000 (UTC) (envelope-from ludovit.koren@gmail.com) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HbQw41Rwyz53FY; Fri, 22 Oct 2021 14:00:04 +0000 (UTC) (envelope-from ludovit.koren@gmail.com) Received: by mail-wr1-x433.google.com with SMTP id z14so3997800wrg.6; Fri, 22 Oct 2021 07:00:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:subject:user-mail-address:date:message-id:user-agent :mime-version; bh=S86SNX7x4Tl0po7j0O/Cp1lfKXXPFchvVWG6av8WyLo=; b=VzmhdM0CJMFEcRHMj2gZVK32xDTg6HCz0P9zRuH9Sj+8LK2+2VrtoRnlto4A5jCCPJ UeiMf3DcASHxh+IpGe6XOuAwbO/HWKBp4A8bkPxFZQTtjGQ6pWmUXLdVv8KgOc2dg9D+ xoFsO2HWBHncB4pCt3m1kIl3EWRlmtv61F74lf4iyQ6JoTGgM/93bRExGFrTKbDINtdf jCWy9XKnpgN3H0ced3UkPSemm7uMHHY+DlPI1V1kXlmP564i0y6lGl/R1fQtcHEVRnGV p39+Xf82hB/y0cjKmc9owkuAYqZnWPhmoJ0dAZ6XcNw13Z0tG9X6NpUAMF2r7snXGtBw 4Dvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:subject:user-mail-address:date :message-id:user-agent:mime-version; bh=S86SNX7x4Tl0po7j0O/Cp1lfKXXPFchvVWG6av8WyLo=; b=gZDOexNThjSgLEK3YG2W9MKt/RRlWawTOpRY2kN7sOyg1taf7LaBePGnEjEpKh0SAS Z6KBltxq9mbYyPN2W4a0IJFLU4MGF1F8B+FAtQJ9EnBJcYSEpAzLqO8Rnfg20GEceLlO T/IZG59PzVxdRPUI6C2l5b4yZuNjkrEtb6cSYzgMAfLu9+lnz98VUg5n4v21M7KFSHiM pd7NFVdcEt9/p/QDGm2z8YhOhqArVfH5uoxFxIievcodk66j5iIeS3zEjWzxSVaxaTBP d7qWx3sr7Reo1f4yUC0t6SHJLpBlx6EYIe/H/NH1G28eYsMPaIre/dAkWTKIwP0051ZE 5SkA== X-Gm-Message-State: AOAM533IuKVtFMrex0k6Lo4svUL30kMT3TL8RAvV7eDAbmh3aNz5kOxP v1u6uIDuH7FPwKh/Rt+aUsQbaqjntws= X-Google-Smtp-Source: ABdhPJzN3iOpc0M6OtO+NqX312PJG1ep1j5LB24Bp6vIG/NwrniPMcys13l+ZG4Ipqf6fDPA2SUvKw== X-Received: by 2002:a5d:5849:: with SMTP id i9mr16493555wrf.331.1634911203281; Fri, 22 Oct 2021 07:00:03 -0700 (PDT) Received: from jedi.localdomain (adsl-dyn9.78-98-181.t-com.sk. [78.98.181.9]) by smtp.gmail.com with ESMTPSA id e2sm3142160wrt.8.2021.10.22.07.00.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Oct 2021 07:00:02 -0700 (PDT) Received: by jedi.localdomain (Postfix, from userid 1001) id 08F731A95E0; Fri, 22 Oct 2021 16:00:02 +0200 (CEST) From: Ludovit Koren To: freebsd-current@freebsd.org, freebsd-net@freebsd.org Subject: LAN ure interface problem User-Mail-Address: ludovit.koren@gmail.com Date: Fri, 22 Oct 2021 16:00:02 +0200 Message-ID: <86sfwt88il.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (berkeley-unix) List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Queue-Id: 4HbQw41Rwyz53FY X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=VzmhdM0C; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of ludovitkoren@gmail.com designates 2a00:1450:4864:20::433 as permitted sender) smtp.mailfrom=ludovitkoren@gmail.com X-Spamd-Result: default: False [-3.62 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.99)[-0.986]; RECEIVED_SPAMHAUS_PBL(0.00)[78.98.181.9:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.63)[-0.634]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::433:from]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi, I have installed FreeBSD 14.0-CURRENT #1 main-n250134-225639e7db6-dirty on my notebook HP EliteBook 830 G7 and I am using RealTek usb LAN interface: ure0 on uhub0 ure0: on usbus1 miibus0: on ure0 rgephy0: PHY 0 on miibus0 rgephy0: OUI 0x00e04c, model 0x0000, rev. 0 rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto ue0: on ure0 ue0: bpf attached ue0: Ethernet address: 00:e0:4c:68:04:20 When there is bigger load on the interface, for example rsync of the big directory, the carrier is lost. The only solution I found is to remove and insert the usb interface; ifconfig ue0 down, ifconfig ue0 up did not help. The output of the ifconfig: ue0: flags=8843 metric 0 mtu 1500 options=68009b ether 00:e0:4c:68:04:20 inet 192.168.1.18 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (100baseTX ) status: active nd6 options=29 I do not know and did not find anything relevant, if the driver is buggy or the hardware has some problems. Please, advice. Regards, lk From nobody Fri Oct 22 15:49:16 2021 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5C5071811FB3 for ; Fri, 22 Oct 2021 15:49:26 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HbTLF0yLNz3sHG; Fri, 22 Oct 2021 15:49:24 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 19MFnG07075681; Fri, 22 Oct 2021 08:49:16 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 19MFnG85075680; Fri, 22 Oct 2021 08:49:16 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202110221549.19MFnG85075680@gndrsh.dnsmgr.net> Subject: Re: cleaning up INET: deprecating network class A/B/C In-Reply-To: <202110192115.19JLFsaR006625@mail.karels.net> To: karels@FreeBSD.org Date: Fri, 22 Oct 2021 08:49:16 -0700 (PDT) CC: "Rodney W. Grimes" , freebsd-net@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 4HbTLF0yLNz3sHG X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd-rwg@gndrsh.dnsmgr.net has no SPF policy when checking 69.59.192.140) smtp.mailfrom=freebsd-rwg@gndrsh.dnsmgr.net X-Spamd-Result: default: False [-2.10 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N > Rod wrote: > > > > I plan to do some cleanup of the residual code defining and using the > > > old Internet network classes (A/B/C), which have been obsolete since > > > CIDR took hold. This is an outline of what I plan, as it will happen > > > in a number of steps and reviews, and I would like feedback on some > > > of it. > > > > > > I want to reduce the use of the obsolete definitions and interfaces, > > > and make it less likely for them to be used going forward. I plan > > > to hide the Class A/B/C bit definitions unless a feature test macro > > > is defined; that will be the default for user code for the moment. > > > A few files in the kernel will need to define the feature test macro > > > for now (but see the next two paragraphs). > > > Sounds good. > > > > > > > Several of the uses of the historical network class macros have to > > > do with generating a default network mask when none is provided. > > > The worst of these is in the code for SIOCAIFADDR (add interface > > > address). I want to have ifconfig and/or the kernel warn about this; > > > the default is most likely wrong. After some time with a warning, > > > it should become an error to set an Internet interface address > > > without a mask (except for loopback and point-to-point interfaces, > > > where the mask is meaningless). > > > Sounds good except that last bit, mask on loopback is > > meaningful, especially for people like me that alrady > > have modified systems that change loopback from 127/8 > > to 127/16. > > I'm not aware of anything that uses the mask on a loopback interface; > are you? There is no network route installed when the loopback address > is set. I think it's similar for point-to-point interfaces, where only > the host route for the destination is added. This is a regression in FreeBSD. Case in point: x230a.dnsmgr.net:root {1003}# route -n get 127.1.1.1 route to: 127.1.1.1 destination: 0.0.0.0 mask: 0.0.0.0 gateway: 192.168.32.8 fib: 0 interface: em0 flags: recvpipe sendpipe ssthresh rtt,msec mtu weight expire So if I try to send packets to 127.1.1.1 they are going to attempt to go out em0, simply WRONG as the netmask on lo0 CLEARLY states they should be via that interface: x230a.dnsmgr.net:root {1004}# ifconfig lo0 lo0: flags=8049 metric 0 mtu 16384 options=680003 inet 127.0.0.1 netmask 0xff000000 ping 127.1.1.1 PING 127.1.1.1 (127.1.1.1): 56 data bytes ping: sendto: Can't assign requested address this should actually be silent with no response.... I would say that FreeBSD is broken here with respect to the loss of the 127.0.0.0/8 via lo0 route. > > > Also care should be taken on point to point, > > I think there is probably a fair bit of code/systems > > out there that MAY still assume /30 or require /30 to > > be set on these, it MAY be an interropt issue to force > > the FreeBSD end to /32. > > Where is the mask ever used on a point-to-point interface? There is > no broadcast address. However, my changes wouldn't break anything > that isn't already broken. This is P2P implementation dependent, iirc both ppp and tun and slip all use to need a /30 and packets sent to the 0 host was discarded, and packets sent to the broadcast address was sent to the far end. Your only looking at current FreeBSD behavior, and I would suggest that a larger sweep be made in the name of interoperability. Also your forcing a POLICY and not simply providing a METHOD. If I want to run a /24 on a p2p link I should be allowed to. > > > > I am tempted to define a new default mask, e.g. 24 bits, for those > > > places that must be able to generate one. An example is NFS BOOTP > > > code. I am interested in feedback on this idea. It would help to > > > reduce use of the old masks, and 8- or 16-bit prefixes are highly > > > unlikely to be correct. Comments on adding a default mask? This > > > would eliminate the use of the old class macros in the kernel. > > > I am not keen on the idea of a default mask at all. I believe > > every place that an IP address -is- used also has the ability > > to specify a netmask. > > The cases that I'm talking about, like the NFS BOOTP code, have two > choices: use a default, or fail (to boot, in this case). I'm not talking > about adding a default anywhere, just changing it to ignore the "class" > of the address. This would also be true when setting a local address > with ifconfig, but that would only be temporary until it starts to return > an error. Can you point specifically at this code so I can get a better understanding of what it is doing? I dont use BOOTP, I use iPXE so I am unfamiliar with this code. > > > > The C library routines inet_netof() and inet_lnaof() should be > > > deprecated, as they use the historical masks. inet_makeaddr() is > > > almost as bad; it works almost by accident as long as a mask is a > > > multiple of 8 bits. I'd like to remove their use from the base > > > system. Unfortunately, I have no idea how much other software uses > > > them. We can at least document them as deprecated and unsafe. > > > Wrap them in a depricating macro, the do a EXP-RUN with that macro > > defined, should get a good idea of that fallout from that. > > EXP-RUN? It is a build of all the ports with a some modification applied, like your patch, so that a change can be tested for impact on ports. > > > I do believe Linux still defines the CLASS macros. > > It does. There are a surprising number of references even in base. And I believe there is a large mass in ports as well. Last time I thought about killing the class macros a quick servey lead me to believe it would break a huge amount of software. I do believe with the work John Gilmore is trying to get done on opening up some of the "reserved" IP space could lead to considerable effort by all OS and software vendors to clean this up, but it is not going to be quick or easy. > Mike -- Rod Grimes rgrimes@freebsd.org From nobody Fri Oct 22 21:06:18 2021 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id CDD5C180A9C0; Fri, 22 Oct 2021 21:06:39 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (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 4HbcNH4yqMz3HBN; Fri, 22 Oct 2021 21:06:39 +0000 (UTC) (envelope-from hps@selasky.org) Received: from [10.36.2.165] (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 910A226019C; Fri, 22 Oct 2021 23:06:31 +0200 (CEST) Message-ID: <9b1b04d9-b715-7986-cb8f-59faef3210e9@selasky.org> Date: Fri, 22 Oct 2021 23:06:18 +0200 List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Subject: Re: LAN ure interface problem Content-Language: en-US To: Ludovit Koren , freebsd-current@freebsd.org, freebsd-net@freebsd.org References: <86sfwt88il.fsf@gmail.com> From: Hans Petter Selasky In-Reply-To: <86sfwt88il.fsf@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4HbcNH4yqMz3HBN X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N On 10/22/21 16:00, Ludovit Koren wrote: > > Hi, > > I have installed FreeBSD 14.0-CURRENT #1 main-n250134-225639e7db6-dirty > on my notebook HP EliteBook 830 G7 and I am using RealTek usb LAN > interface: > > ure0 on uhub0 > ure0: on usbus1 > miibus0: on ure0 > rgephy0: PHY 0 on miibus0 > rgephy0: OUI 0x00e04c, model 0x0000, rev. 0 > rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto > ue0: on ure0 > ue0: bpf attached > ue0: Ethernet address: 00:e0:4c:68:04:20 > > > When there is bigger load on the interface, for example rsync of the big > directory, the carrier is lost. The only solution I found is to remove > and insert the usb interface; ifconfig ue0 down, ifconfig ue0 up did not > help. The output of the ifconfig: > > ue0: flags=8843 metric 0 mtu 1500 > options=68009b > ether 00:e0:4c:68:04:20 > inet 192.168.1.18 netmask 0xffffff00 broadcast 192.168.1.255 > media: Ethernet autoselect (100baseTX ) > status: active > nd6 options=29 > > I do not know and did not find anything relevant, if the driver is buggy > or the hardware has some problems. Please, advice. > > Regards, > Not the same device, but similar issue: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258057 --HPS From nobody Sat Oct 23 09:47:25 2021 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 292381808D34 for ; Sat, 23 Oct 2021 09:47:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HbxG605WHz4XGS for ; Sat, 23 Oct 2021 09:47:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id AC02520217 for ; Sat, 23 Oct 2021 09:47:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 19N9lPiV044512 for ; Sat, 23 Oct 2021 09:47:25 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 19N9lPBZ044511 for net@FreeBSD.org; Sat, 23 Oct 2021 09:47:25 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 258874] route add -inet 240/4 results in 0.0.0.0/4 127.0.0.1 UGRS lo0 Date: Sat, 23 Oct 2021 09:47:25 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 13.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: melifaro@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D258874 --- Comment #7 from Alexander V. Chernikov --- I'm going to close it with 'work as expected' on November 1 if there are no other objections. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sat Oct 23 13:45:07 2021 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 86886181B7B3; Sat, 23 Oct 2021 13:45:19 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:13b:39f::9f:25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Hc2Xb2kptz4YNM; Sat, 23 Oct 2021 13:45:19 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 310DD8D4A216; Sat, 23 Oct 2021 13:45:11 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 0A0FBE707D2; Sat, 23 Oct 2021 13:45:10 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id I55m6LH-gbGh; Sat, 23 Oct 2021 13:45:08 +0000 (UTC) Received: from [169.254.86.56] (unknown [IPv6:fde9:577b:c1a9:4902:55af:59c8:5fe6:788]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 6E302E707D1; Sat, 23 Oct 2021 13:45:08 +0000 (UTC) From: "Bjoern A. Zeeb" To: "Ludovit Koren" Cc: freebsd-current@freebsd.org, freebsd-net@freebsd.org Subject: Re: LAN ure interface problem Date: Sat, 23 Oct 2021 13:45:07 +0000 X-Mailer: MailMate (2.0BETAr6151) Message-ID: <32F1A26F-582A-4E48-96E7-5955FB680DCA@lists.zabbadoz.net> In-Reply-To: <86sfwt88il.fsf@gmail.com> References: <86sfwt88il.fsf@gmail.com> List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4Hc2Xb2kptz4YNM X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On 22 Oct 2021, at 14:00, Ludovit Koren wrote: > Hi, > > I have installed FreeBSD 14.0-CURRENT #1 = > main-n250134-225639e7db6-dirty > on my notebook HP EliteBook 830 G7 and I am using RealTek usb LAN > interface: > > ure0 on uhub0 > ure0: = > on usbus1 > miibus0: on ure0 > rgephy0: PHY 0 on miibus0 > rgephy0: OUI 0x00e04c, model 0x0000, rev. 0 > rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, = > 1000baseT-FDX, 1000baseT-FDX-master, auto > ue0: on ure0 > ue0: bpf attached > ue0: Ethernet address: 00:e0:4c:68:04:20 > > > When there is bigger load on the interface, for example rsync of the = > big > directory, the carrier is lost. The only solution I found is to remove > and insert the usb interface; ifconfig ue0 down, ifconfig ue0 up did = > not > help. The output of the ifconfig: > > ue0: flags=3D8843 metric 0 mtu = > 1500 > options=3D68009b > ether 00:e0:4c:68:04:20 > inet 192.168.1.18 netmask 0xffffff00 broadcast 192.168.1.255 > media: Ethernet autoselect (100baseTX ) > status: active > nd6 options=3D29 > > I do not know and did not find anything relevant, if the driver is = > buggy > or the hardware has some problems. Please, advice. I found that issuing a usbconf reset usually helps to bring it back. That said I have a machine with a port on a root hub directly and there = it behaves a lot better compared to when I connect it to different port = on the 2nd root hub with an intermediate uhub on the same machine. /bz From nobody Sat Oct 23 14:57:54 2021 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id AB363181CE38 for ; Sat, 23 Oct 2021 14:57:57 +0000 (UTC) (envelope-from mike@mail.karels.net) Received: from mail.karels.net (mail.karels.net [216.160.39.52]) by mx1.freebsd.org (Postfix) with ESMTP id 4Hc48N0bjhz3Cxr for ; Sat, 23 Oct 2021 14:57:55 +0000 (UTC) (envelope-from mike@mail.karels.net) Received: from mail.karels.net (localhost [127.0.0.1]) by mail.karels.net (8.16.1/8.16.1) with ESMTPS id 19NEvtoL023437 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 23 Oct 2021 09:57:55 -0500 (CDT) (envelope-from mike@mail.karels.net) Received: (from mike@localhost) by mail.karels.net (8.16.1/8.16.1/Submit) id 19NEvsmc023436; Sat, 23 Oct 2021 09:57:54 -0500 (CDT) (envelope-from mike) Message-Id: <202110231457.19NEvsmc023436@mail.karels.net> To: "Rodney W. Grimes" cc: freebsd-net@FreeBSD.org From: Mike Karels Reply-to: karels@freebsd.org Subject: Re: cleaning up INET: deprecating network class A/B/C In-reply-to: Your message of Fri, 22 Oct 2021 08:49:16 -0700. <202110221549.19MFnG85075680@gndrsh.dnsmgr.net> List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <23434.1635001074.1@mail.karels.net> Content-Transfer-Encoding: quoted-printable Date: Sat, 23 Oct 2021 09:57:54 -0500 X-Rspamd-Queue-Id: 4Hc48N0bjhz3Cxr X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of mike@mail.karels.net has no SPF policy when checking 216.160.39.52) smtp.mailfrom=mike@mail.karels.net X-Spamd-Result: default: False [0.30 / 15.00]; HAS_REPLYTO(0.00)[karels@freebsd.org]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[mike]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; REPLYTO_ADDR_EQ_FROM(0.00)[]; DMARC_NA(0.00)[freebsd.org]; AUTH_NA(1.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[karels@freebsd.org,mike@mail.karels.net]; RCVD_NO_TLS_LAST(0.10)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:209, ipnet:216.160.36.0/22, country:US]; FROM_NEQ_ENVFROM(0.00)[karels@freebsd.org,mike@mail.karels.net]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N > > Rod wrote: > > = > > > > I plan to do some cleanup of the residual code defining and using = the > > > > old Internet network classes (A/B/C), which have been obsolete sin= ce > > > > CIDR took hold. This is an outline of what I plan, as it will hap= pen > > > > in a number of steps and reviews, and I would like feedback on som= e > > > > of it. > > > > = > > > > I want to reduce the use of the obsolete definitions and interface= s, > > > > and make it less likely for them to be used going forward. I plan > > > > to hide the Class A/B/C bit definitions unless a feature test macr= o > > > > is defined; that will be the default for user code for the moment. > > > > A few files in the kernel will need to define the feature test mac= ro > > > > for now (but see the next two paragraphs). > > = > > > Sounds good. > > = > > > > = > > > > Several of the uses of the historical network class macros have to > > > > do with generating a default network mask when none is provided. > > > > The worst of these is in the code for SIOCAIFADDR (add interface > > > > address). I want to have ifconfig and/or the kernel warn about th= is; > > > > the default is most likely wrong. After some time with a warning, > > > > it should become an error to set an Internet interface address > > > > without a mask (except for loopback and point-to-point interfaces, > > > > where the mask is meaningless). > > = > > > Sounds good except that last bit, mask on loopback is > > > meaningful, especially for people like me that alrady > > > have modified systems that change loopback from 127/8 > > > to 127/16. > > = > > I'm not aware of anything that uses the mask on a loopback interface; > > are you? There is no network route installed when the loopback addres= s > > is set. I think it's similar for point-to-point interfaces, where onl= y > > the host route for the destination is added. > This is a regression in FreeBSD. Case in point: > x230a.dnsmgr.net:root {1003}# route -n get 127.1.1.1 > route to: 127.1.1.1 > destination: 0.0.0.0 > mask: 0.0.0.0 > gateway: 192.168.32.8 > fib: 0 > interface: em0 > flags: > recvpipe sendpipe ssthresh rtt,msec mtu weight expire > So if I try to send packets to 127.1.1.1 they are going to attempt > to go out em0, simply WRONG as the netmask on lo0 CLEARLY states > they should be via that interface: > x230a.dnsmgr.net:root {1004}# ifconfig lo0 > lo0: flags=3D8049 metric 0 mtu 16384 > options=3D680003 > inet 127.0.0.1 netmask 0xff000000 Routes do not use the netmask on interface addresses, but only on the rout= e. The only address that is reachable via lo0 is what is configured. Long ag= o, I remember driving a Sun workstation to its knees by doing "ping 127.0.0.2= ", which it would "send" via the loopback, receive it, then try to forward until hit the hop limit. That inspired the change in the route. I haven't done the archaeology, but I believe the change from net route to host route was in 4.3BSD (1986). Similarly for point to point: there are only host routes to the remote and local addresses (the latter via the loopback). > ping 127.1.1.1 > PING 127.1.1.1 (127.1.1.1): 56 data bytes > ping: sendto: Can't assign requested address > this should actually be silent with no response.... Ideally, there would be a reject route to the loopback "net" that would cause 127.1.1.1 to be unreachable. But you see why there are "Martian" filters that refuse to forward packets to the "loopback". > I would say that FreeBSD is broken here with respect to the > loss of the 127.0.0.0/8 via lo0 route. If it is broken, I think it has always been broken. > > = > > > Also care should be taken on point to point, > > > I think there is probably a fair bit of code/systems > > > out there that MAY still assume /30 or require /30 to > > > be set on these, it MAY be an interropt issue to force > > > the FreeBSD end to /32. > > = > > Where is the mask ever used on a point-to-point interface? There is > > no broadcast address. However, my changes wouldn't break anything > > that isn't already broken. > This is P2P implementation dependent, iirc both ppp and tun and slip > all use to need a /30 and packets sent to the 0 host was discarded, > and packets sent to the broadcast address was sent to the far end. I'm not so sure about this; I didn't think slip or ppp had any idea of broadcast or a zero host. But it doesn't affect the current discussion (see below). > Your only looking at current FreeBSD behavior, and I would suggest > that a larger sweep be made in the name of interoperability. Also > your forcing a POLICY and not simply providing a METHOD. If I want > to run a /24 on a p2p link I should be allowed to. I'm not proposing any change in policy. If some links require a specific mask, they should be configured with it. With the change I'm proposing, the default would change from 8/16/24 bits depending on class to 24 bits in any default case. > > = > > > > I am tempted to define a new default mask, e.g. 24 bits, for those > > > > places that must be able to generate one. An example is NFS BOOTP > > > > code. I am interested in feedback on this idea. It would help to > > > > reduce use of the old masks, and 8- or 16-bit prefixes are highly > > > > unlikely to be correct. Comments on adding a default mask? This > > > > would eliminate the use of the old class macros in the kernel. > > = > > > I am not keen on the idea of a default mask at all. I believe > > > every place that an IP address -is- used also has the ability > > > to specify a netmask. > > = > > The cases that I'm talking about, like the NFS BOOTP code, have two > > choices: use a default, or fail (to boot, in this case). I'm not talk= ing > > about adding a default anywhere, just changing it to ignore the "class= " > > of the address. This would also be true when setting a local address > > with ifconfig, but that would only be temporary until it starts to ret= urn > > an error. > Can you point specifically at this code so I can get a better > understanding of what it is doing? I dont use BOOTP, > I use iPXE so I am unfamiliar with this code. It's src/sys/nfs/bootp_subr.c. I don't know the circumstances in which it is used (e.g. whether it is used with DHCP for diskless boot). > > = > > > > The C library routines inet_netof() and inet_lnaof() should be > > > > deprecated, as they use the historical masks. inet_makeaddr() is > > > > almost as bad; it works almost by accident as long as a mask is a > > > > multiple of 8 bits. I'd like to remove their use from the base > > > > system. Unfortunately, I have no idea how much other software use= s > > > > them. We can at least document them as deprecated and unsafe. > > = > > > Wrap them in a depricating macro, the do a EXP-RUN with that macro > > > defined, should get a good idea of that fallout from that. > > = > > EXP-RUN? > It is a build of all the ports with a some modification applied, like > your patch, so that a change can be tested for impact on ports. There are enough references in the base system that I think I'll just mark the routines deprecated in the man page and in comments in the header. Some of the base system is not worth changing (e.g. rarp). Mike > > = > > > I do believe Linux still defines the CLASS macros. > > = > > It does. There are a surprising number of references even in base. > And I believe there is a large mass in ports as well. Last time > I thought about killing the class macros a quick servey lead me > to believe it would break a huge amount of software. > I do believe with the work John Gilmore is trying to get > done on opening up some of the "reserved" IP space could > lead to considerable effort by all OS and software vendors > to clean this up, but it is not going to be quick or easy. > > Mike > -- = > Rod Grimes rgrimes@freeb= sd.org From nobody Sat Oct 23 15:39:16 2021 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D128018056CA for ; Sat, 23 Oct 2021 15:39:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Hc5444YvHz3Pnc for ; Sat, 23 Oct 2021 15:39:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 6C8EE246CC for ; Sat, 23 Oct 2021 15:39:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 19NFdG8h066095 for ; Sat, 23 Oct 2021 15:39:16 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 19NFdGw2066094 for net@FreeBSD.org; Sat, 23 Oct 2021 15:39:16 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 258874] route add -inet 240/4 results in 0.0.0.0/4 127.0.0.1 UGRS lo0 Date: Sat, 23 Oct 2021 15:39:16 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 13.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: karels@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D258874 --- Comment #8 from Mike Karels --- I also have mixed feelings about this. I dislike the code that was removed= .=20 But the fact that 240/4 or 10/8 used to mean something useful and now mean something not useful suggests that the quoted bit of code should be restore= d.=20 Another option might be to warn if the pattern specified has bits not under= the mask (i.e. in the "host part"). But I think the best option is to restore = the quoted code. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sat Oct 23 17:21:36 2021 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 76A241812F3D; Sat, 23 Oct 2021 17:21:41 +0000 (UTC) (envelope-from ludovit.koren@gmail.com) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450: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 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Hc7LD1CCxz4fw3; Sat, 23 Oct 2021 17:21:40 +0000 (UTC) (envelope-from ludovit.koren@gmail.com) Received: by mail-ed1-x529.google.com with SMTP id z20so2250813edc.13; Sat, 23 Oct 2021 10:21:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:user-mail-address:date:in-reply-to :message-id:user-agent:mime-version; bh=VtOSrvjjqE8tYjBNwCswk23U81r2YtkgsVN8iGMGswQ=; b=FVDfnISVuqbjIXZbR8OT07AzJV487yybTqhYl8gqgA4sZI7otgldObgg6c1pY5Pwra EJT+HpPmiXFGYRFt9nXzB9Z5eYF+QpXYP+3a2TNbI/ztWIxtJ+lCpLtqzTDxa31i+nIB LyPzch4bQztbIk2jcEIcHnbDhCo9PgMoVq6pBPZaHDb80rkffTeyXd8uIUYsmpaRz75a 3MEeH2Nb9OdsQigjGAgb15oUszkCZk3k/7kN6Ra78n2W6yWwj1izKCXadImZv0/k+W/P fchqSk0Wj2StQfYbD33ITxAjg1VJ5KA6r3VxANbGwgyQrLKvd0rDPD0pQ8YqSJQA7CBj Laqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:user-mail-address :date:in-reply-to:message-id:user-agent:mime-version; bh=VtOSrvjjqE8tYjBNwCswk23U81r2YtkgsVN8iGMGswQ=; b=1wjL7aiMlWKn5TgyTzf4RTf4Nad4FxpWBcYLm4mZtPh/XJLAN0YfnDAs6bdbT91CK1 M4ILhQSwZqJSwf8+8eM+u/IOZ2P/WAbXi/3Ep+wQwEn3HiiNf1NvXesWfWVp0RJMpSvQ CbmD4eCdIKIpBuQOzibZswGoP9Ji9LvC4py1oR0x6MAAC/mGTWgIohdM4vsSZghxZLED 2nrqzbHAI5ja7kUPsgBE+2lLj16g0pMoU375fpLA1/o4FhbqKhANsFpd/d7kGHFM00C7 gvVEvTnVZQWAG3zU4ECMOtbLxTm+CZqpWfr8PVrD+5b5D5TFhWLiwQZsqtmqNUtCsSNT HCXQ== X-Gm-Message-State: AOAM530GIvbEsaMo7iqaMMzEmTKOwxtd9DHniQwhUf3JfoR3ZKxfJVc9 v8btvbbtBTv+6WMR07TQkm9/1Qnk3BE= X-Google-Smtp-Source: ABdhPJyvCRYPQsQ9QcUeAWlahA25wBvFL/Ja+ySzv8NZdg1VNnAYpaUGUPZK1kuRbuD4bu6DDfQpKw== X-Received: by 2002:aa7:da16:: with SMTP id r22mr10863960eds.75.1635009699121; Sat, 23 Oct 2021 10:21:39 -0700 (PDT) Received: from jedi.localdomain (adsl-dyn9.78-98-181.t-com.sk. [78.98.181.9]) by smtp.gmail.com with ESMTPSA id v22sm868106edr.93.2021.10.23.10.21.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 23 Oct 2021 10:21:38 -0700 (PDT) Received: by jedi.localdomain (Postfix, from userid 1001) id EA10D1A8031; Sat, 23 Oct 2021 19:21:36 +0200 (CEST) From: Ludovit Koren To: Hans Petter Selasky Cc: freebsd-current@freebsd.org, freebsd-net@freebsd.org Subject: Re: LAN ure interface problem References: <86sfwt88il.fsf@gmail.com> <9b1b04d9-b715-7986-cb8f-59faef3210e9@selasky.org> User-Mail-Address: ludovit.koren@gmail.com Date: Sat, 23 Oct 2021 19:21:36 +0200 In-Reply-To: <9b1b04d9-b715-7986-cb8f-59faef3210e9@selasky.org> (Hans Petter Selasky's message of "Fri, 22 Oct 2021 23:06:18 +0200") Message-ID: <86pmrv7j33.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (berkeley-unix) List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Rspamd-Queue-Id: 4Hc7LD1CCxz4fw3 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=FVDfnISV; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of ludovitkoren@gmail.com designates 2a00:1450:4864:20::529 as permitted sender) smtp.mailfrom=ludovitkoren@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; HAS_ATTACHMENT(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RECEIVED_SPAMHAUS_PBL(0.00)[78.98.181.9:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::529:from]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: Y --=-=-= Content-Type: text/plain >>>>> Hans Petter Selasky writes: > On 10/22/21 16:00, Ludovit Koren wrote: >> Hi, >> I have installed FreeBSD 14.0-CURRENT #1 >> main-n250134-225639e7db6-dirty >> on my notebook HP EliteBook 830 G7 and I am using RealTek usb LAN >> interface: >> ure0 on uhub0 >> ure0: on usbus1 >> miibus0: on ure0 >> rgephy0: PHY 0 on miibus0 >> rgephy0: OUI 0x00e04c, model 0x0000, rev. 0 >> rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto >> ue0: on ure0 >> ue0: bpf attached >> ue0: Ethernet address: 00:e0:4c:68:04:20 >> When there is bigger load on the interface, for example rsync of the >> big >> directory, the carrier is lost. The only solution I found is to remove >> and insert the usb interface; ifconfig ue0 down, ifconfig ue0 up did not >> help. The output of the ifconfig: >> ue0: flags=8843 metric 0 mtu >> 1500 >> options=68009b >> ether 00:e0:4c:68:04:20 >> inet 192.168.1.18 netmask 0xffffff00 broadcast 192.168.1.255 >> media: Ethernet autoselect (100baseTX ) >> status: active >> nd6 options=29 >> I do not know and did not find anything relevant, if the driver is >> buggy >> or the hardware has some problems. Please, advice. >> Regards, >> > Not the same device, but similar issue: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258057 I don't know if I understand it right.The issue is with dropping power... Mine is holding power right: usbconfig ugen1.1: <0x8086 XHCI root HUB> at usbus1, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA) ugen0.1: <0x8086 XHCI root HUB> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA) ugen0.2: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA) ugen0.3: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA) ugen0.4: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA) ugen0.5: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA) ugen1.2: at usbus1, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (72mA) I am attaching the usbdump -d 1.2 when it stops working. lk --=-=-=-- From nobody Sun Oct 24 21:00:24 2021 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 49CCE181023B for ; Sun, 24 Oct 2021 21:00:25 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Hcr886df8z4m5p for ; Sun, 24 Oct 2021 21:00:24 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 935C71C435 for ; Sun, 24 Oct 2021 21:00:24 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 19OL0OC7077767 for ; Sun, 24 Oct 2021 21:00:24 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 19OL0OWX077766 for net@FreeBSD.org; Sun, 24 Oct 2021 21:00:24 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202110242100.19OL0OWX077766@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: net@FreeBSD.org Subject: Problem reports for net@FreeBSD.org that need special attention Date: Sun, 24 Oct 2021 21:00:24 +0000 List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="16351092247.c923E.76593" Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: Y --16351092247.c923E.76593 Date: Sun, 24 Oct 2021 21:00:24 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- In Progress | 221146 | [ixgbe] Problem with second laggport New | 204438 | setsockopt() handling of kern.ipc.maxsockbuf limi New | 213410 | [carp] service netif restart causes hang only whe Open | 7556 | ppp: sl_compress_init() will fail if called anyth Open | 166724 | if_re(4): watchdog timeout Open | 193452 | Dell PowerEdge 210 II -- Kernel panic bce (broadc Open | 200319 | Bridge+CARP crashes/freezes Open | 202510 | [CARP] advertisements sourced from CARP IP cause Open | 207261 | netmap: Doesn't do TX sync with kqueue Open | 222273 | igb(4): Kernel panic (fatal trap 12) due to netwo Open | 225438 | panic in6_unlink_ifa() due to race Open | 227720 | Kernel panic in ppp server Open | 230807 | if_alc(4): Driver not working for Killer Networki Open | 236888 | ppp daemon: Allow MTU to be overridden for PPPoE Open | 236983 | bnxt(4) VLAN not operational unless explicit "ifc Open | 237072 | netgraph(4): performance issue [on HardenedBSD]? Open | 237840 | Removed dummynet dependency on ipfw Open | 238324 | Add XG-C100C/AQtion AQC107 10GbE NIC driver Open | 238707 | Lock order reversal: rtentry vs "nd6 list" Open | 240944 | em(4): Crash with Intel 82571EB NIC with AMD Pile Open | 241106 | tun/ppp: panic: vm_fault: fault on nofault entry Open | 241162 | Panic in closefp() triggered by nginx (uwsgi with Open | 241191 | route flush panic with RADIX_MPATH Open | 243463 | ix0: Watchdog timeout Open | 247111 | pxeboot very slow with i219LM Open | 257709 | netinet6: Set net.inet6.icmp6.nodeinfo default to Open | 118111 | rc: network.subr Add MAC address based interface 27 problems total for which you should take action. --16351092247.c923E.76593--