(old)Puppy Linux Discussion Forum

Posted: **Sat 25 Aug 2007, 13:10**

I've found a bug in rc.network that may help explain why the ifplugstatus function has been unreliable ever since execution of rc.network was put into the background in Puppy 2.14, ie, executed as a separate process from rc.local0.

The problem lies in line 114 (Puppy 2.17.1):

Code: Select all

read -t ${TRY_DELAY} a

This command does not work correctly when rc.network is run in the background. The line does not produce a delay. I've tested this by monitoring the loop to a temp file with the 'date' command and the number of iterations.

I commented-out line 114 and the following line, as interrupting the loop when run in the background with "Enter" makes no sense, and added this line:

Code: Select all

sleep ${TRY_DELAY}

So the complete patch looks like this:

Code: Select all

    if [ "`ifplugstatus${IFVER} ${INTERFACE} | grep "link beat detected"`" = "" ]; then
     #read -t ${TRY_DELAY} a
     #[ $? -eq 0 ] && TRY_COUNT=${TRY_MAX_COUNT}
     #pakt: 'read -t <delay>' doesn't work when rc.network is run as a separate process
     sleep ${TRY_DELAY} #use this instead
    else
     UNPLUGGED='false'
     TRY_COUNT=${TRY_MAX_COUNT}
    fi

Original code from Puppy 2.17.1:

Code: Select all

    if [ "`ifplugstatus${IFVER} ${INTERFACE} | grep "link beat detected"`" = "" ]; then
     read -t ${TRY_DELAY} a
     [ $? -eq 0 ] && TRY_COUNT=${TRY_MAX_COUNT}
    else
     UNPLUGGED='false'
     TRY_COUNT=${TRY_MAX_COUNT}
    fi

Previously, on an Acer with the wireless interface set up, rc.network did not start the interface since the link beat took 2.5 sec to start. It now works at every boot

Posted: **Sun 26 Aug 2007, 00:17**

Thanks for the info, I'll implement the fix.

Posted: **Tue 11 Sep 2007, 21:59**

Hi; will this fix initiate eth1 (wireless in my case) if eth0 (wired) is unplugged? If so it's just what I've been looking for.

I have found that Puppy remembers and then only tries to initialise the first network interface you configure. Should you ever switch to the alternative the network wizard has to be re-run every time.

If it doesn't do that now but could be made to then what would have to be changed to add that functionality?

Nick

Posted: **Wed 12 Sep 2007, 13:31**

I have been running puppy 2.17 with the network wizard and dhcp upgrades. I did the upgrades trying to get around the following problem:

I use a belkin usb wireless device to connect to the internet. If I leave it plugged in to my USB hub (or maybe if I leave it plugged in period) during bootup, the machine won't boot up. It hangs at the "looking for networks..." line. (Can't remember the exact message but it's where it waits for the DHCP connection.) If I unplug the usb wireless device, so that I have exactly zero network devices, the machine boots up fine. I then plug in my usb device, configure using the new network wizard and everything works flawlessly.

The little bit of investigation I did showed that the timer loop never timed out, which seems to relate directly to this bug.

I guess the thing to do is download the new script and give it a try, which I will do. I just thought you guys might want to know that bootup hangs while trying to connect to the network have been a continuing problem. It was happening for the ethernet connection too, because I moved the computer to a location where there was only wireless but left the internet card in. I got around that by using the boot wizard to disable loading etho.

Like I said, I'll give new code a whirl and report back.

(old)Puppy Linux Discussion Forum

Bugfix: rc.network in Puppy 2.14 through 2.17.1

Bugfix: rc.network in Puppy 2.14 through 2.17.1

Could this fix my bootup hang?