From nobody Mon Mar 20 19:36:35 2023 X-Original-To: freebsd-stable@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 4PgQ3N0S5Qz408Gq for ; Mon, 20 Mar 2023 19:36:48 +0000 (UTC) (envelope-from nagy.attila@gmail.com) Received: from mail-oa1-x36.google.com (mail-oa1-x36.google.com [IPv6:2001:4860:4864:20::36]) (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 4PgQ3M2d2Nz4cQc for ; Mon, 20 Mar 2023 19:36:47 +0000 (UTC) (envelope-from nagy.attila@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=kK7epXx7; spf=pass (mx1.freebsd.org: domain of nagy.attila@gmail.com designates 2001:4860:4864:20::36 as permitted sender) smtp.mailfrom=nagy.attila@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-oa1-x36.google.com with SMTP id 586e51a60fabf-17683b570b8so14072188fac.13 for ; Mon, 20 Mar 2023 12:36:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679341006; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=0d8U4Qv1GMN4+qCHDZ/Gew3r7lkipZcGXK0mAYwtF78=; b=kK7epXx7nkeCW4zBwDorIr+U4/QYG/IqcLahy08Sq1+VE0NDQZ+rxyF0asbz5M85xA Vjl9r5PUQsj4b52ChoYUsVobWXa6Xc+y3m0vuaX9xyl4KgQ5x5Z0OsNmasnJvCfbQwR7 IrRdQid7etYg7esd9TWPbniuwJvjcZL5OWZuAM7bUCAM/gWBa4OPQ6FF2PBOZcb92TwD uQ+u+TfensqrzbAnfsSFMJoPDFXwh2b29Zu4takgYEIflCSSoswNyoQbaUwHMk1DICpV fS1e0Bmn3N7zXLFxjdNLxzhgQrCnlG71HxThuNircnjcnZHVeYN+HRMsIkhuXgCm8nT9 yWbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679341006; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=0d8U4Qv1GMN4+qCHDZ/Gew3r7lkipZcGXK0mAYwtF78=; b=I1e1xXGO86fXjkq4TnrMxLczKbSt7WoA3SpYkCE1QkOLF2MBfOKU3q0W0vyOIaqCXY HeNVJm92UCZQMI/05G5wlAjPh5Ily50LWmWAAxKpO+HLr+USxz/7ZUXBPpj1xf2lu633 bgusfdgLSrghAsL0srZFy98iy4WHdKAG1+vxYzNuew5XRgBkk/QFrsXs4HGpgqnwYd20 Gm3WoYqIWEDSjoBheSJHnLeO3vKZeM0+ObwuCX/ChNI29PnCGFoR9/W8A6s8itTeBykO SwATB3hJF5twYgvP0groq2zOMxxj4XxKKtBbITPb4jMIMjCbZje+dX/k+fTZtQ7v5zsW Hnug== X-Gm-Message-State: AO0yUKXjNMbhLHIgVg2wMv+zTGl71MqK568ayfpezr7dEyHYkpf58GtH X2cd/6B9p0h3sPYU6zkFsxl2ij0NBYlFAei+rb+4aw60Gys= X-Google-Smtp-Source: AK7set+JYb3PoMoe/rjHCFNhVdkYAGeRjuIYD8SADai1kbxGq+RhMOZbqDHydxmCAd+XnIqci0suSQ685pC4HCIiR1Y= X-Received: by 2002:a05:6871:250d:b0:17a:bf87:63f4 with SMTP id yx13-20020a056871250d00b0017abf8763f4mr3010831oab.11.1679341006668; Mon, 20 Mar 2023 12:36:46 -0700 (PDT) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 References: <1634f44f-cb69-ee74-5300-4a8c414850f4@grosbein.net> In-Reply-To: <1634f44f-cb69-ee74-5300-4a8c414850f4@grosbein.net> From: Attila Nagy Date: Mon, 20 Mar 2023 20:36:35 +0100 Message-ID: Subject: Re: Fwd: Kernel DHCP unpredictable/fails (PXE boot), userspace DHCP works just fine To: Eugene Grosbein Cc: freebsd-stable@freebsd.org Content-Type: multipart/alternative; boundary="00000000000028c72e05f75a0c36" X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.987]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2001:4860:4000::/36:c]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2001:4860:4864:20::36:from]; ARC_NA(0.00)[]; TAGGED_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2001:4860:4864::/48, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_TLS_LAST(0.00)[] X-Rspamd-Queue-Id: 4PgQ3M2d2Nz4cQc X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N --00000000000028c72e05f75a0c36 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Eugene Grosbein ezt =C3=ADrta (id=C5=91pont: 2023. m= =C3=A1rc. 19., V, 0:16): > 19.03.2023 5:01, Attila Nagy wrote: > > > Sometimes UEFI/BIOS SETUP has some settings for ACPI/HPET timers > (enable/disable), > > did you try "playing" with such options? > > > > Nope, I haven't thought about that. > > It's enabled (default setting). > > Another possible reason: DHCP packets sent from DHCP client have 1-bit > flag indicating > if client wants to receive an answer as unicast or broadcast UDP packet. > > You could try hacking source to force broadcasts and see if that changes > things. > This NIC's driver has previous history of bad in-chip filtering packets i= n > transit > from the wire to the host (CPU). > Thanks a lot for the great ideas! Although if I follow the code right, this is already set: https://github.com/freebsd/freebsd-src/blob/c3179891f897d840f578a5139839fca= cb587c96d/sys/nfs/bootp_subr.c#L1246 If you have the time to take a look at my patched kernel outputs, I think the response datagrams get to the UDP stack. What I feel is either they doesn't make it to the soreceive call sometimes or the whole process gets reset for some reason. --00000000000028c72e05f75a0c36 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Eugene Grosbein <eugen@gros= bein.net> ezt =C3=ADrta (id=C5=91pont: 2023. m=C3=A1rc. 19., V, 0:16= ):
19.03.2023 5:= 01, Attila Nagy wrote:

>=C2=A0 =C2=A0 =C2=A0Sometimes UEFI/BIOS SETUP has some settings for ACP= I/HPET timers (enable/disable),
>=C2=A0 =C2=A0 =C2=A0did you try "playing" with such options?<= br> >
> Nope, I haven't thought about that.
> It's enabled (default setting).

Another possible reason: DHCP packets sent from DHCP client have 1-bit flag= indicating
if client wants to receive an answer as unicast or broadcast UDP packet.
You could try hacking source to force broadcasts and see if that changes th= ings.
This NIC's driver has previous history of bad in-chip filtering packets= in transit
from the wire to the host (CPU).
Thanks a lot for the great= ideas!
Although if I follow the code right= , this is already set:
https://github.com/freebsd/freebsd-src/blob/c3= 179891f897d840f578a5139839fcacb587c96d/sys/nfs/bootp_subr.c#L1246
=

If you have= the time to take a look at my patched kernel outputs, I think the response= datagrams get to the UDP stack. What I feel is either they doesn't mak= e it to the soreceive call sometimes or the whole process gets reset for so= me reason.

--00000000000028c72e05f75a0c36--