Posted: Tue Jul 29, 2008 23:33 Post subject: problem with v24 sp1 x86 (solution found)
I installed v24 sp1 to my CF card today, but have a problem with the web interface. Everything works fine until I change the default password. You are forced to do this in sp1 btw. After the password change the web interface no longer works (httpd crashes) and the router reboots few seconds later. I can access the router using telnet, but don't really know what to do to fix the problem.
I'm using the registred version and I've tried reinstalling the image several times to my cf card using the dd command. I have even written zeros to partition 1-3, leaving only partition 4 intact which has my key. But the end result is always the same. Rebooting the router does not help.
Anyone have this problem or know a solution? Thanks in advance
Last edited by xaim00 on Sun Aug 24, 2008 20:31; edited 3 times in total
I also have had similar issues. After the default password changing, the webgui looks like a basic text file ish and then causes the router to do a reboot about a minute or two afterwards. this is on a a7n8x-e motherboard
I've tried in both internet explorer and firefox, i will try opera too later today.
I guess I could update the bios, but that will have to wait until i get hold of a gfx card.
The motherboard I'm using is an old MSI neo2 platinum with nforce3 chipset.
I did not have this issue in v24 (final), so it must be something specific to sp1.
Will post an update later today or tomorrow when i have more time to mess with it ..Also, anyone know if it is possible to bypass the forced password change using telnet?
Sorry for the late update. I've been trying to find a solution to this problem for the past week. At the moment I have found a temporary solution that works. I'll get to that in a moment.
First I've tried to replicate this problem on different hardware/motherboard (intel chipset), but can not. So it looks like this issue might be tied to nforce chipset.
I've done a lot of experimentation on manually changing the password/username in nvram. The password gets changed and works, but the web interface becomes inaccessible. On occasion I've managed to bypass the forced password change by messing around in the nvram, funny thing is I can not replicate this on will. It doesn't matter if I repeat the exact same command sequence, so there seems there is some kind of random factor to it.
However, during the times i managed to skip the forced password change, the router worked fine. No problems at all configuring it. I could even without any problems change the password in Administration>management-tab and the web interface continued to work fine...
...So I devised a way to change the password in the admin-tab instead of the 'forced password change'.
Code:
REMOVED! See my new solution in the next post instead.
Using this command is essentially the same thing as changing the password in the admin>management-tab and hit apply. The great thing is, this works every time! The only downside I've found as of yet is that you need to run this command every time the router reboots. I have no idea why, but if i don't the web interface become inaccessible.
If anyone wants to use this command you are doing so at your own risk! Change it to suit your needs. In its current form it expects the router ip to be 192.168.1.1 and the new password will be "newpass"
Edit: Several times now this command have failed to bring up the web interface after a reboot. Don't know why, but the only way for me to get it back is to reset the nvram (writing zeros to partition3).
Last edited by xaim00 on Sun Aug 24, 2008 3:22; edited 2 times in total
Good news! I have finally found a simple way to fix this problem.
By studying httpd.c on dd-wrt svn i came across this code snippet:
Code:
if (endswith (file, "changepass.asp"))
{
if (nvram_invmatch ("status_auth", "0"))
file = "Info.htm";
else
file = "index.asp";
}
As it turns out, when changing the password on the first boot (forced change), the nvram variable status_auth doesn't get set to "0" as it should. So to fix this problem simply set it to "0" manually.
Edit: After further research i don't think this variable is the real culprit. I think it only controlls weather the info page should be available or not. It's possible that some code on the info page crashes the http-deamon, and disabling it cures the problem.
On a new install before accessing the web interface, login using telnet and do the following commands.
Code:
setuserpasswd root yournewpassword
nvram set status_auth="0"
nvram commit
Last edited by xaim00 on Tue Aug 26, 2008 1:08; edited 1 time in total
I've found another simple solution that doesn't disable the info page.
By setting the nvram varible probe_blacklist to "eth1 eth2 eth3", everyting works perfectly for me.
Here is what i did:
1. Clearing the nvram (write zeros to partition3)
Code:
dd if=/dev/zero of=/dev/discs/disc0/part3
reboot
2. Setting the probe_blacklist variable
Code:
nvram set probe_blacklist="eth1 eth2 eth3"
nvram commit
3. Use the web interface and do the forced password change.
4. Add step 2 to a startup script, because probe_blacklist gets unset on every reboot.
I'm not to sure why probe_blacklist should be set to "eth1 eth2 eth3", my setup also have eth0, eth4, eth5. Well, it works, enough for me. (Edit1: i tried adding all my wired interfaces to probe_blacklist and it still works fine).
Edit2: This fix seem to work perfectly, no craches as of yet. probe_blacklist is used in wl.c (dd-wrt svn), my guess is that it protects wired interfaces from being probed as a wireless interface.
I've found another simple solution that doesn't disable the info page.
By setting the nvram varible probe_blacklist to "eth1 eth2 eth3", everyting works perfectly for me.
Here is what i did:
1. Clearing the nvram (write zeros to partition3)
Code:
dd if=/dev/zero of=/dev/discs/disc0/part3
reboot
2. Setting the probe_blacklist variable
Code:
nvram set probe_blacklist="eth1 eth2 eth3"
nvram commit
3. Use the web interface and do the forced password change.
4. Add step 2 to a startup script, because probe_blacklist gets unset on every reboot.
I'm not to sure why probe_blacklist should be set to "eth1 eth2 eth3", my setup also have eth0, eth4, eth5. Well, it works, enough for me. (Edit1: i tried adding all my wired interfaces to probe_blacklist and it still works fine).
Edit2: This fix seem to work perfectly, no craches as of yet. probe_blacklist is used in wl.c (dd-wrt svn), my guess is that it protects wired interfaces from being probed as a wireless interface.
Thank you! This fixed my issues as well. nicely done
