Broadcom wireless doesn't connect at boot

Actually, I seem to recall seeing a page that came to your exact conclusion, and rightly so. IIRC, the solution was to move the DHCPc initialization further back in the /etc/init.d sequence.

Home of the Point-N-Click Help Files
http://www.catb.org/~esr/faqs/smart-questions.html

I had the same problem.

I'm running Fedora Core 5, 2.6.18 kernel, latest ndiswrapper, the XP drivers, a Belkin F5D7050 card, took off the 4KB stack stuff from the kernel, and all the other crap you have to do, and it all works great, except that it doesn't connect when I boot up.

What I found out is the time the system gives the card to associate itself with the access point (AP) and get a link is just not enough time, especially if you're using encryption--I am using WEP encryption.

On my system, and not using WEP, the wireless NIC takes between 7 and 15 seconds to associate with the wireless AP (my Linksys router). With WEP, I've clocked it at 35 - 40 seconds.

The timeout is controlled by a function called check_link_down() in the file /etc/sysconfig/network-scripts/network-fuctions (Fedora Core 5).

The way it works is the script ifup-eth (etc/sysconfig/network-scripts) calls the function check_link_down() which checks your wireless link (wlan0 on my system--wlan is considered an eth device) to see if it is connected to the AP. If there is no link between the card and the AP it fails and you get the "no link present, check cable?" message at boot.

The tool that checks if the link is present is ethtool, and it is called in the check_link_down function.

The wireless card has to sync up to the AP, and if it's encrypted it takes a bit longer (naturally).

So, what I did to make it work was just give the card more time to sync up. Check_link_down() looks like so (ignore the stupid

<br/>

<br />
check_link_down ()<br />
{<br />
    if [ -x /sbin/mii-tool -o -x /sbin/ethtool ]; then<br />
        if ! LC_ALL=C ip link show dev $1 2>/dev/null| grep -q UP ; then<br />
	   ip link set dev $1 up >/dev/null 2>&1<br />
	fi<br />
	timeout=0<br />
	while [ $timeout -le 10 ]; do<br />
	    check_mii_tool $1<br />
	    m=$?<br />
	    check_ethtool $1<br />
	    e=$?<br />
	    if [ $m -eq 1 ] || [ $e -eq 1 ] ; then<br />
		return 1<br />
	    fi<br />
	    if [ $m -eq 2 ] && [ $e -eq 2 ] ; then<br />
		return 1<br />
	    fi<br />
	    usleep 500000<br />
	    timeout=$((timeout+1))<br />
	done<br />
	return 0<br />
    fi<br />
    return 1<br />
}<br />

So, what you can see from that is we have a timeout counter ($timeout), which increments up to 10 times. If we get to 10 and the link still isn't present then we've timed out and we get the fail message.

Looking further down, we see usleep 500000. That means we wait for .5 seconds each time we loop through the while statement to give the link a chance to sync up.

If you multiply 10 tries by .5 seconds a try, you find out your wireless card only has 5 seconds to sync up with the access point. This is probably not enough time, especially if you're using WPA or WEP.

My fix was easy, I just changed the usleep 500000 (.5 seconds) to usleep 5000000 (5 seconds).

You won't have to wait the entire 50 seconds though, because the while loop has a return statement that breaks the loop if the link is present. You only have to wait long enough for ethtool to see a good link (mine ususally takes 7 passes through to get sync'd up).