Bugfix: rc.network in Puppy 2.14 through 2.17.1

News, happenings
Post Reply
Message
Author
User avatar
pakt
Posts: 1157
Joined: Sat 04 Jun 2005, 16:54
Location: Sweden

Bugfix: rc.network in Puppy 2.14 through 2.17.1

#1 Post by pakt »

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 :)
Methinks Raspberry Pi were ideal for runnin' Puppy Linux

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#2 Post by BarryK »

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

nic2109
Posts: 405
Joined: Mon 01 Jan 2007, 20:24
Location: Hayslope, near Middlemarch, Midlands, England

#3 Post by nic2109 »

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

swarnick
Posts: 21
Joined: Tue 26 Dec 2006, 03:21

Could this fix my bootup hang?

#4 Post by swarnick »

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.

Post Reply