[If you reply please split follow-ups to dhcp-client@isc.org
tech-net@netbsd.org as appropriate. I am not on the former list.]

In message <20030903195506.GA22912@rek.tjls.com>Thor Lancelot Simon writes
>On Wed, Sep 03, 2003 at 12:37:27PM -0700, Bryan Vyhmeister wrote:
>> 
>> I followed your instructions and commented out what you said to. I then
>> built a new kernel and restarted. My dmesg output did show that the
>> patch was being used but it did not solve the problem. When I plugged in
>> a network cable it reported 1000base-T but when I ran dhclient it went
>> back to 100base-T and then got an IP address. When I first ran dhclient,
>> it sent out several requests and then by the fourth or fifth it
>> apparently switched to 100base-T and got its IP address.

It may be the dsp patch is not correct. I dont have a 5703 to test,
unfortunately. (Anyone want to swap for a 5700 or 5701?)


>It's my experience that the way dhclient treats the interface (repeatedly
>configuring it down and up, which causes a reset on many interfaces) plays
>*very* poorly with a large number of gigabit devices.  I've seen it hang
>old Tigon cards so hard that a power-cycle was required in order to get
>them back into a working state, and I would not be surprised to see it
>do something similar with the bge.  I've also seen it get Intel cards stuck
>in a state in which they always mis-negotiate the duplex.
>
>Adding appropriate media options to your dhclient configuration, for
>example 'medium "media 1000baseT-FDX ip4csum udp4csum tcp4csum"' *and*
>increasing the dhclient retry interval, which will keep it from resetting
>the interface hardware so often, may help.
>
>I've long noticed that the first packet dhclient sends on my NetBSD
>systems, regardless of interface hardware type, always seems to be lost,
>so it always retries at least once, resetting the interface in the
>process.  This isn't a good thing, either, but I've never figured out
>why it happens.

If the adjacent switch does spanning tree, then the link-down/link-up
should force the switch into hold down (waiting to either see ( or not
see) an STP advertisement, and then infer presence (or absence) of a
switch on that port.

If an interface is already up when dhclient gets its hands on it, I
think that makes an execllent argument that dhclient shouldn't bounce
the interface down, then up, at least not until its deep into its
backoff/retry cycle.