From nobody Sat Mar 18 09:55:49 2023 X-Original-To: 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 4PdxGG5ksBz3yNbD for ; Sat, 18 Mar 2023 09:56:06 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (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 4PdxGD4R0dz3rly for ; Sat, 18 Mar 2023 09:56:04 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cs.huji.ac.il header.s=57791128 header.b=WkDYtdO4; spf=none (mx1.freebsd.org: domain of danny@cs.huji.ac.il has no SPF policy when checking 132.65.116.210) smtp.mailfrom=danny@cs.huji.ac.il; dmarc=pass (policy=none) header.from=huji.ac.il DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version:Content-Type:Message-Id:From; bh=slwsP0d7DFpXIlPByBbNPJcsRqccYiN+Hqn5V/Bq0rM=; b=WkDYtdO41XGKAW7yLqDlwCnSOSCyQnKxoW6smuj50HZWZm5wq8bOThG7tsmXEhcJqy6V0R8zAuR1LPityKrYVinmayg84HLZT6ao5yLCWBGrLQC4ygCcS9DEFWtyL156EwWT2uarv51CGlrbXz3phoIZaCYCywEGHpVivVqUggtbNtVEu/VsjNWqs/Ie4MWWqsSb1AMZBA6CqOLtwCRKQfpPV57JYlUWlyuourKgheqiOXzSjpZUMyKCtMMX86UyosoIrpmTsJSu4gIZh6frTP8bMqqmGYYJKYxXebGSPjHd0jX8D98L+Z/0omVOoVC4UwBvEESYUkyRBMEWgfln5Q==; Received: from imac.bk.cs.huji.ac.il ([132.65.179.42] helo=smtpclient.apple) by kabab.cs.huji.ac.il with esmtp id 1pdTI7-000Id0-Aw; Sat, 18 Mar 2023 11:55:59 +0200 From: Daniel Braniss Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_09293E36-95E4-4BC4-ACE0-1BE2793A1AAF" 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 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) Subject: Re: Kernel DHCP unpredictable/fails (PXE boot), userspace DHCP works just fine Date: Sat, 18 Mar 2023 11:55:49 +0200 In-Reply-To: Cc: Matthias Pfaller , stable@freebsd.org To: Attila Nagy References: <0b95a502-eea0-46cc-5d0d-ec6e861ad51f@marco.de> X-Mailer: Apple Mail (2.3731.300.101.1.3) X-Spamd-Result: default: False [-3.29 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.991]; DMARC_POLICY_ALLOW(-0.50)[huji.ac.il,none]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[cs.huji.ac.il:s=57791128]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ASN(0.00)[asn:378, ipnet:132.64.0.0/15, country:IL]; MLMMJ_DEST(0.00)[stable@freebsd.org]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; R_SPF_NA(0.00)[no SPF record]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FREEFALL_USER(0.00)[danny]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[cs.huji.ac.il:+]; FROM_HAS_DN(0.00)[]; TAGGED_RCPT(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4PdxGD4R0dz3rly X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_09293E36-95E4-4BC4-ACE0-1BE2793A1AAF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 17 Mar 2023, at 22:16, Attila Nagy wrote: >=20 > Matthias Pfaller > ezt =C3=ADrta = (id=C5=91pont: 2023. m=C3=A1rc. 17., P, 7:24): >>=20 >> Do you have STP/RSTP enabled on the switch ports? When the link goes = down when=20 >> switching from firmware mode to kernel mode, the port will go back to = blocking. When=20 >> the dhcp requests don't make it to the dhcp server because of this = and the link goes=20 >> down and up again while retrying (don't know if this happens) you = will get the same=20 >> problem on the next try. As a simple test you could put a dumb = unmanaged switch=20 >> between your core network and the server. > Thanks for the idea, but I don't think this might be the case. > I can see the UDP datagrams coming into the kernel (replies to DHCP = messages). take look at src/stand/libsa/bootp.c, there is a compile option that = allows many more options to be transferred via dhcp =E2=80=A6=20 BTW, where possible I=E2=80=99m moving to uefi, since pxeboot is = failing with file to large =E2=80=A6 another issue i have with pxeboot,=20 older versions work - better - , some are terribly slow, and some just hang. danny --Apple-Mail=_09293E36-95E4-4BC4-ACE0-1BE2793A1AAF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 17 = Mar 2023, at 22:16, Attila Nagy <nagy.attila@gmail.com> = wrote:

Matthias Pfaller <leo@marco.de> ezt =C3=ADrta = (id=C5=91pont: 2023. m=C3=A1rc. 17., P, 7:24):

Do you have STP/RSTP enabled on the switch ports? When the link goes = down when
switching from firmware mode to kernel mode, the port will go back to = blocking. When
the dhcp requests don't make it to the dhcp server because of this and = the link goes
down and up again while retrying (don't know if this happens) you will = get the same
problem on the next try. As a simple test you could put a dumb unmanaged = switch
between your core network and the server.
Thanks = for the idea, but I don't think this might be the case.
I can = see the UDP datagrams coming into the kernel (replies to DHCP = messages).

take look at src/stand/libsa/bootp.c, = there is a compile option that allows many
more options to be = transferred via dhcp =E2=80=A6 

BTW, where = possible I=E2=80=99m moving  to uefi, since pxeboot is failing with = file to large =E2=80=A6

another issue i have = with pxeboot, 
older versions work - better - , some are = terribly slow,
and some just = hang.

danny

= --Apple-Mail=_09293E36-95E4-4BC4-ACE0-1BE2793A1AAF--