udhcpc: sending discover -- increase timeout?

[mig39]

I’m having an issue with some computers where my switch doesn’t finish negotiating speed/duplex, doing spanning-tree, etc, before the udhcpc process tries three times.

Watching it in person, it looks like the interface on the switch comes up literally a second after the 3rd attempt to get a lease. Here’s a photo of the error I’m getting:

My question is: can I have this process try 4 or 5 times instead of 3 times? Is this a setting or piece of code I can alter somewhere?

[Sebastian Roth]

@mig39 Unfortunately it’s not as simple as changing a setting. Although it’s not too hard to change the script code I am wondering why you think it would work trying longer.

I suppose this is a Spanning Tree issue. Please connect a dumb Mini switch between the computer and your main switch. See if that makes a difference.

[george1421]

@mig39 It does sound like a spanning tree issue where you are not using one of the fast spanning tree protocols. The ideal solution is to update/fix your switches to use a fast spanning tree protocol (fstp, fast-stp, mstp, etc).

The hacker way (not intended to be a bad term only methodology) would be either to unpack the inits, update them, and then repack the init or use a post init script to replace/update the /etc/init.d/S40network network startup script in FOS and then change the value on line #37 to some number larger than 3. As seen here: https://github.com/FOGProject/fos/blob/master/Buildroot/board/FOG/FOS/rootfs_overlay/etc/init.d/S40network

[mig39]

Thanks, will try a dumb switch and report back. And I can always adjust (or turn off) the spamming tree stuff on the switch, as it’s usually not connected to other switches.

The reason I think just a second or two longer delay would work is that I literally watched the light on the switch interface it is orange while negotiating and doing its thing, then green when it’s fully connected. The green happens literally a second after the third attempt

The initial PXE boot from the laptop works just fine, BTW.

[mig39]

As predicted, it was the spanning tree protocol on the Cisco switch.

I verified it worked just fine with a dumb switch connected through the Cisco switch. And it worked just fine.

So I just turned off Spanning Tree on the switch, since it’s a standalone switch.

Thanks for your help!

[george1421]

@mig39 I would only turn off spanning tree on a switch where you have 100% control of the switch ports. If any of the switch ports are user facing I would not disable spanning tree. Your cisco switch should support rapid-stp or fast-stp. That is all that is needed. Then you don’t run the risk of a loopback taking down your network.