Date: Fri, 13 Jul 2018 15:56:00 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 229727] On install, Broadcom chipset doesn't receive DHCPOFFER Message-ID: <bug-229727-7501-3JHRlmeqcM@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-229727-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-229727-7501@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D229727 --- Comment #5 from Rodney W. Grimes <rgrimes@FreeBSD.org> --- (In reply to Stephan Neuhaus from comment #4) My experience has been that STP interacts very poorly with any clients tryi= ng to do DHCP as the normal time for STP to decide a port is NOT connected to another switch is on the order of 30 seconds, which is frequently beyond the timeouts of DHCP request/offer cycles. Some machines well work, some well not, and it is all very flackey until you either turn STP off on the port, = or set it to fast mode. Part of the problem is that boot time stuff likes to reset NIC's, and resetting the NIC drops carrier, which causes the STP deci= sion all over. This is especially annoyed when chain loading from a native PXE = to iPXE, often leading to iPXE load failures. The only way to remove this variable is to either make sure STP is off on t= he port, or set to stp fast mode. Using the same switch for both client/server does NOT remove stp from the p= ath, that single switch should still be trying to do stp. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-229727-7501-3JHRlmeqcM>