Mitch... I did some tests and I have confirmed that wep on the virutal ssid's is broken on the first stable-generic version of autoap firmware, but it works perfectly with the dd-wrt.v24_AAPw_102-generic.bin version... the 102 version kills the nocat splash daemon when you use the web log instead of syslog, just FYI for everyone else keeping track...
dd-wrt.v24_AAPw_102-generic.bin works well as far as I can tell and has fixes that Mathilda and JP got together on and the wep works with it, both on the uplink side of the scanner part of it and on the downlink side with the virtual ssid's...
Now, here is what I have come up with after thinking and reading and thinking some more on this for quite some time now...
1) The next obvious step for autoap is to add another nvram variable that is a list of ssid's that are called "preferred ssid's"... This list will be scanned for in order of first to last, and these ssid's will always take precidence over other open ssid's regardless of their signal strength.. At least as long as they can maintain a valid connection...
2) The next step, as far as I can see it, will be to take a major departure from this existing script and almost start completely over with the same basic framework, and build the WDS structure, and then merge the two script components back together in the end, for one big final product...
This second step would be to do pretty much like mitchsavage is suggesting we do manually and scan the area for all signals, make a list of them, just like autoap does now, only then we will sort these signals based on several attributes, such as their ssid's, mac addresses, signal quality, etc..
The script would then take this list and if any of the devices it detected during the site survey were freindly AP's related to our network, then it would add each one of them to the WDS table under WIRELESS/ WDS, and turn itself to AP mode instead of Repeater Mode, and the system would become its first level of an automatic mesh network with one source of internet, and it would have the intelligence to have two different backup methods of connecting to the internet.. One would be to connect to just one of the friendly AP's with the autoap repeater mode, and the final resort would be to scan for any open wifi and connect to that, as we have accomplished now...
That would be a good next step and a reasonable bite for us to chew on for awhile..
I can see it going to more layers after that, but if we keep breaking this down like this, then we will keep making progress..
Let me hear from you guys what you think of this..
I tried root/admin in the login window.
"TGL-1-AUTOAP-2" at http://192.168.10.1
It will not accept the user and password. I used these bins downloaded here
dd-wrt_v23sp2_autoap-wrt54g.bin
autoap_client_nvrambak.bin
What user/password do I use if root/admin does not work.
Is it a possibility that the bin had the wrong use/password in it, or could it be corrupted?
Everything seems to be Ok up to the login.
Thanks for the work you're doing here. It makes the DD-WRT project more interesting.
Happy New Year
Slick54
Update: I just reset the router. I got access back. But noticed that I'm back to square one. I'll wait until I see if there was something up with the bin's password before I reinstall it again. After reseting the router the login is back to the original DD-WRT login.
Thanks again
Last edited by Slick54 on Tue Jan 02, 2007 14:07; edited 2 times in total
just wanted to give an update i was a real fool trying /user/autotap.htm !!! when it is actually /user/autoap.htm i put an extra t and was getting all the blank page!! thanks and it works good but i feel the ddwrt v24 repeater mode is excellent for my purpose thanks again bs and all the ddwrt communty and a Happy New year
Slick54 - next time don't use nvram backup file. If the firmware that made that backup is different from yours, you will have problems. Use nvram variables instead.
As for the latest Dec 28 version dd-wrt.v24_AAPw-stable_generic.bin, it didn't work for me on Buffalo WHR-G54S - I could manually connect to an open ssid using Site Survey but the script kept trying to connect to other open networks, without success. While older version dd-wrt.v24_AAPw_102-generic.bin seemed to work fine before on WHR-HP-G54.
I didn't have much time to test though, cause the testing was done at my relatives house. Will get back if I find some more.
Hi guys.. I will answer a few of these questions here.. First off.. the password for the nvrambak.bin file for the first config is the default "admin"...
It clearly says:
IP = 192.168.10.1
user = root
pass = admin
That first setup is for the SP2 version of autoap.. I have found that when you restore a config from V24 to SP2 or vice versa, the password does not make the trip in the restore function and you are locked out of the router just like you describe...
I will go back and change that post now to simply point to the wiki page so it will have the latest of everything to try...
I would suggest just following that exact install the first time through and go through the control panel and see what the setup is all about.. Then take the newest version, which is actually the 102-generic version, not the stable-generic, it was one version precious to 102,,,, and replicate the config with that firmware..
As soon as I have five minutes, I will post another config file that is especially for the 102-generic.bin firmware...
Also, I agree that some of the changes in the newest version made it work better in some regards and worse in others.. One remedy for that is to run through marcjohnson's Universal Wireless Repeater method, which takes this exact same script and loads it into factory firmware and runs it on the fly, thereby allowing you to tweak it... although that takes some serious knowledge to know what the heck to tweak in there...
I will go put that link to the wiki in that first tutorial post, since that is so out of date now, because I agree that newcomers should get pointed straight to the latest versions of everything...
1) Does it contain something that you cannot set by AutoAP NVRAM variables?
2) Doesn't it have all the other setting for DD-WRT that the user might have wanted differently?
3) Even if firmware is the same, can't the NVRAM content be a bit different on different router models?
NVRAM commit in startup script: I already made some small fixes to AutoAP wiki page. Today I suddenly realized something and was about to make another change but decided to ask you guys first. Since, you know, I'm a bit new ...
Right now wiki tells you to activate built-in AutoAP script by putting this in startup
Code:
nvram set autoap_logger="html"
nvram commit
/bin/autoap &
DD-WRT explanation of NVRAM is a bit too short, so I had to consult with this explanation in OpenWRT Wiki. In my understanding, nvram commit in startup script doesn't make any sence at all and it just shortens the life of your flash chip.
You either do just once
Code:
nvram set autoap_logger="html"
nvram commit
and then you put in startup
Code:
/bin/autoap &
Or you have this in startup and it works the same way
p1415... The nvrambak.bin file is not needed at all.. It is just a basic configuration for people who have no idea how to get started... if you know how to setup client mode and repeater mode, then it is not needed at all....
nvram commit needs only be run one time.. It does not need to permanatly be stored in nvram... Personally, I don't think you will boot your router a million times in its life and burn out the nvram chip, but it is a thought to consider.. Not needed though.. That is only to get the variable set one time..
Most of those things are for new people who are not on this level and who just want to get it going and play with it...
I hope this helps.. Thanks for your time and input on the wiki page...
Now about firmwares. I extracted (see DD-WRT Wiki: Development) both firmwares mentioned earlier.
(Needed to take that path anyway, cause also I want to try to put AutoAP on my Belkin F5D7230 v1444 with only 2Mb flash - need micro DD-WRT version)
Found out that they both contain outdated AutoAP scripts:
dd-wrt.v24_AAPw-stable_generic.bin: /bin/autoap: Dec 06, 2006
dd-wrt.v24_AAPw_102-generic.bin: /bin/autoap: Dec 12, 2006
and the difference between scripts is minor (changes in html logging)
While standaloneAutoAP script seems to have a lot of fixes, including taking ssid name in quotes when calling aap_checkjoin(). I think that's why v24_AAPw-stable_generic.bin didn't work for me earlier - I had spaces in the name of open ssid.
Well, I hope I will be able to update the script and rebuild the firmware for me, but what about other people? Could the maintainers of the project please clarify what's happening with built-in AutoAP firmwares?
p1415... this narrows down a few issues that will alow JP to take that info and roll it into another firmware build... I have the saem issues, as many of us do...
We go in and out of phases of working on this, as we all work to survive... I am sure JP will come back and take this info and roll our another build...
I realize I haven't released on a very consistent schedule, and am duly sorry. As this has progressed, there have been a ton of new ideas on my part, wo-fo's part, and indeed a commendable amount from the community. My development paradigm has been to integrate a feature sloppily, then move on to the next, and finally correct the bugs when I feel like we're at an ideal release point.
This is a bad practice, and in the future I'll try to integrate a feature, correct its bugs, then release.
At the moment, however, I've still got a few kinks to iron out. The next release will definitely include the latest autoap script, with the ability to update, and if the other dev agrees on its readiness, a new section in the web ui to set autoap variables.
Henceforth releases will come in two flavors, SP3 and V24. If demand is high, I'll build micro and mini versions as well. As new routers become more prevelant, and if someone is willing to donate one to the cause, I'll build for other platforms as well.
Also, I feel like I should point out again that BrainSlayer's (and indeed the other developers') work is what drives this. I definitely don't want anyone to feel like this is firmware designed by me. It's not. I just modified their already excellent work.
Joined: 12 Dec 2006 Posts: 60 Location: Geneva, Switzerland
Posted: Tue Jan 09, 2007 12:28 Post subject: some more fixes
Back in the new year, I have some more fixes for the autoap script to offer:
- removed variable inet_two (was unused). This is rather cosmetic, but cleaned it out as I tried to understand the whole thing more in detail. Maybe it is legacy.
- update cur_wip in aap_init_scan(). It was not updated, so the second pass failed always
- put ssid to join in quotes, to handle spaces in SSIDs
- wait aap_dhcpw after dhcp renewal in aap_checkjoin()
Meanwhile I did some bigger overhaul of the functions aap_checkjoin and aap_inet_ch. This is because I ran into random weirdnesses and decided to make it more structured and more comprehensible (at least for me) . The result should connect faster and more reliable, however it still needs some testing. The results of these efforts are available at http://irisa.free.fr/autoap_test.sh
Once this is confirmed to work reliably, I plan to review the remaining funtions. I hope this is of help for JP to improve his code. I am sorry, however, if in my ignorance I removed some beautiful code of yours. Feel free, of course, to revert or modify.
Last edited by mathilda on Thu Jan 11, 2007 9:13; edited 1 time in total
Thanks Mathilda... Your awesome.. We are buried in some other things, such as life and work, but will be back to this shortly.. Glad to see you chipping away at the stone...
Joined: 12 Dec 2006 Posts: 60 Location: Geneva, Switzerland
Posted: Thu Jan 11, 2007 12:02 Post subject: script cleanup update
I have some more modifications to offer:
- make it insist more on internet ping to avoid changing AP for no reason
- for some reason DD-WRT is not reliably assigning a GW address.
(nvram get wan_gateway). This is maybe a problem of the latest nightlies
that I use, I don't know. Anyway, now the script tolerates this behavior.
- cleanup aap_inet_chk more. 24 lines down from 39
- getting rid of $logparse. This was a mechanism to delay the check for the logsize
limit. The corresponding function is now called less often, which makes it obsolete.
- restructure aap_init_scan() some (no recursive calls, leave the checking
to aap_checkjoin() )
This combined with the previous changes is running smoothly on my setup. You can get it as usual at http://irisa.free.fr/autoap.sh
Next will be to figure out how to fix the wep-connection thing in an elegant way.
. The result should connect faster and more reliable, however it still needs some testing. The results of these efforts are available at