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=229727 --- 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 trying 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 decision 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 the port, or set to stp fast mode. Using the same switch for both client/server does NOT remove stp from the path, that single switch should still be trying to do stp. -- 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>