New 1.0.4.6 based custom firmware

[Hacksaw]

the rc.local isn't being executed when the router reboots. Any ideas why not?

I will ask the obvious question: Did you rc.local move it to /shares/MYVOLUME1 and chmod the file to 775?

I guess I should ask the other question: How do you know it is not getting executed?

[glenmaroney]

I will ask the obvious question: Did you rc.local move it to /shares/MYVOLUME1 and chmod the file to 775?

I guess I should ask the other question: How do you know it is not getting executed?

Unfortunately, I have got it in the right place and I chmod ed it to 755...should it be 775?

I know it's not being executed because after a reboot I have to modify the path and mount /opt again.

[Hacksaw]

Unfortunately, I have got it in the right place and I chmod ed it to 755...should it be 775?

Sorry, typo on my part. It should be 755.

Have you tried executing the operations in the rc.local file separately to determine if they are valid? I am wondering if the if statements are not getting through properly.

Hacksaw.

[BrianKDav]

The two lines in rc.local assume the pre-existence of two exports: PATH and LD_LIBRARY_PATH. After some fiddling, I found that PATH existed on my system, but LD_LIBRARY_PATH did not. This seemed to break the second export in my system, so I changed it from

export LD_LIBRARY_PATH=/opt/lib:${LD_LIBRARY_PATH}

to a simpler

export LD_LIBRARY_PATH=/opt/lib:/shares/lib

This was done in both rc.local and .profile. After that, ipkg and other things behaved more to expectation.

Dropbear never starts automatically for me. Anyone have an idea why

if [ \! -a /var/run/dropbear.pid ]; then

is not working for me?

--Brian

BTB: Here's to you, kfurge, for all your work and continued support. Thank you!

[kfurge]

This was done in both rc.local and .profile. After that, ipkg and other things behaved more to expectation.

Same for my .profile. I agree rc.local should match.

Dropbear never starts automatically for me. Anyone have an idea why

if [ \! -a /var/run/dropbear.pid ]; then

is not working for me?

Does this it work OK when executed under a standard login shell? If so, you might be seeing a busybox shell quirk. If not, please post more of your rc.local file. Maybe the shell is terminating prior to executing the if statement?

An interesting quirk I found is that the busybox /bin/shell, when executing a script under a login shell, properly sets $VAR in the following:

VAR=`/bin/pwd`

but when the same script is executed directly from the kernel as a replacement for /bin/miscio_input_change (which is called whenever one of the buttons is pressed) $VAR remains empty. Writing to syslog indicated that /bin/pwd executed OK. However, the shell refused to set the variable regardless of what I tried.

- K.C.

[BrianKDav]

Here's the entire rc.local

#!/bin/sh

pool=`nvram get apps_pool`
share=`nvram get apps_share`
internal_hdd=/dev/ide/host2/bus0/target0/lun0/disc

if [ \! -f /tmp/rc.local.done ]; then

# Indicate we've already done this
touch /tmp/rc.local.done

#
# Mount /opt and connect in various system files
#
if [ -e /shares/${pool}/opt ]; then
mount -o bind /shares/${pool}/opt /opt

cat /proc/mounts > /opt/etc/fstab

ln -s /opt/etc/shells /tmp/shells
ln -s /opt/etc/fstab /tmp/fstab

export PATH=/opt/bin:/opt/sbin:${PATH}
export LD_LIBRARY_PATH=/opt/lib:/shares/lib
fi

# Start utelnetd on local interface only!
/apps/bin/utelnetd -i br0 &

# Test for and start dropbear
echo "dropbear?" | logger -p local0.notice
if [ \! -a /var/run/dropbear.pid ]; then
echo "dropbear!" | logger -p local0.notice
/opt/etc/init.d/S51dropbear
echo "dropbear started" | logger -p local0.notice
fi

# Stop & Start web server
echo "thttpd" | logger -p local0.notice
killall thttpd
/apps/bin/thttpd -dd /shares/webbase -p 8081 -i /var/run/thttpd.pid -v

# Add confirmation that rc.local was executed
echo "rc.local executed" | logger -p local0.notice

fi

Not much different from your samples...

I'll try rebooting if necessary to review the log messages.

--Brian

[kfurge]

Not much different from your samples...

Yep, that should work OK. Any chance that the dropbear startup script is not set as executable?

- K.C.

[Hacksaw]

Quick question as I am slightly confused. I have just gone throught he instructions for building the 1.0.4.6 based firmware and am now up to applying K.C.'s modifications.

http://home.comcast.net/~kfurge/wl700ge.html indicates in step 2.3 to "cd to ./exinstall/apps/bin" but I don't have an apps directory under exinstall. Here is the path I found rcex under: /opt/WL700g/nasoc/src/apps/tarfiles/exinstall/bin

Is this the file I should be looking for?

Here is another one. Step 6.1 states:

# Disable the config rewrite nonsense in $(apps)/Makefile by commenting out the line immediately under the "busybox:" target label.

I assume then that this line would be the one that starts with "cd busybox"?

busybox:
        cd busybox && rm -f .config && ln -s NASoC_config .config
        $(MAKE) -C busybox dep
        $(MAKE) -C busybox STRIPTOOL=$(STRIP)

I guess I leave the "cd busybox" command in and remove the rest?

Thanks,
Hacksaw.

[kfurge]

Here is the path I found rcex under: /opt/WL700g/nasoc/src/apps/tarfiles/exinstall/bin

Is this the file I should be looking for?

It's been a while since I posted the instructions, and I've modified my build environment since, but I believe you're right. The makefile uses exinstall.tar to build the image so you'll have to tar up any of your changes in the exinstall directory back to exinstall.tar to make them stick.

I guess I leave the "cd busybox" command in and remove the rest?

Comment out the whole line.

- K.C.

[Hacksaw]

Thanks K.C.!

I have rebuilt the image using your instructions and attempted to apply the iptables recent module support. I have applied the patches to the kernel and rebuilt it, but am having issues getting the libipt_recent.so built. I might not need it, so i am going to flash the load I have and see what happens.

Hacksaw.

[oclee]

I locked myself out of my shell (no telnet, no valid shell for ssh), so cannot get into my WL700.

Although I have tried various approaches described on the forum, I cannot prevent the rc.local in /MYVOLUME1/ from being executed (and preventing me from logging in). The telnet hack described, does not work for me (see my other post http://wl500g.info/showthread.php?t=8858).

Therefore I was wondering if a previous version of Kfurge's firmware might do the trick. Especially the one that expects an rc.local in /MYVOLUME1/MYSHARE1/. This location I can reach (by nfs) and can modify files in.

I'm thinking that downgrading to that custom firmware might force the WL700 to use the rc.local in /MYSHARE1/ which I could make to enable telnet. Right?

Only problem, Kfurge doesnt offer this version for download, and I do not know which version of Kfurge's firmware it should be. Can anybody help me with this? Thanks.


Downgrading to the previous version worked like a charm...

[LeperKing]

To get previous version of Kfurge's firmware, go to post 36 of this thread!

LK

[oclee]

To get previous version of Kfurge's firmware, go to post 36 of this thread!
LK

Right... that was the one thing I didn't search the whole forum for... *oops*
Thanks!

[BrianKDav]

I locked myself out of my shell (no telnet, no valid shell for ssh), so cannot get into my WL700.

Did that myself once, and had to resort to the hack where you put the telnet startup in one of the cgi scripts. Only problem was that I couldn't mark as executable the script I wanted to use to start telnet. (This I could see by failures to execute, and a directory command in FTP access.) I got around the inability to mark it executable it by putting the script, with the executable properties already set, on a USB drive. This was done from my Ubuntu system - not sure how to do it with Windows. I then plugged the USB drive in and hit copy. Once the script was in the USBCOPY folder, I used FTP to copy it to a location accessible in a browser session. Invoking the cgi via a browser started telnet (on br0, of course).

I hope this helps!

--Brian

Here's the link to telnet / cgi hack. My only problem is that, as mentioned above, I couldn't make the CHMOD command work.
http://www.wl500g.info/showthread.php?t=7434

[BrianKDav]

Yep, that should work OK. Any chance that the dropbear startup script is not set as executable?

- K.C.

Nope, it's set executable. If the ASUS box is starting due to a power failure, do you think it could be actually finding the dropbear.pid file? I thought the /var/run folder got rebuilt and/or cleared on a restart. Sometimes these computers frustrate us by doing exactly what we tell them to do!

--Brian

As I get moments here and there, I want to improve the message logging on this system.