the AP in the building is a DSL Modem/Access point, and it's own default gateway is a public IP in the 213.132.33.0/24 subnet so i doubt that's the case
anyway, i will change the IPs once i get to the office later on
till then, is there anyway to trigger logging for the client mode?
i'd love to see an IP conflict or any other error in syslog, rather than guessing what could be wrong :S
This is something that I am not positive of but I think you turn on Syslogd under SERVICES and enter the address of your log server.. Then I think you have to go into the log settings and turn them all on..
After that, if I am not mistaken, you will be getting syslog information at your server.. This is just theory, as I have been told in short how to do this, but I still do not have it worked out, mainly because I have not had time to play with the whole thing in depth yet...
Even though the main internet router has its own IP range, somewhere there must be a router set to 192.168.1.1 or why would the other one be set to 192.168.2.1?
I just have a strong feeling that you have everything set correctly and it is this simple IP conflict matter messing you up...
Hey MJ... I just noticed something regarding the issue you are having with the windows XP client losing its DHCP lease after awhile...
Under ADMINISTRATION / SERVICES there is a checkbox that says, "Use NVRAM for client lease DB".... In all other versions of dd-wrt, this box is checked by default... In V24 (at least 021206 build) both of the boxes there are unchecked by default, leaving nowhere to store the client lease DB... I am pretty sure that if you check the NVRAM box, your system will maintain the DHCP leases...
I will let you know for sure very shortly.... I am working my way up on this... If I can get this to run from /jffs and not have to load the script every reboot, then I think you might have something major here...
i dropped by my office to give this another shot..
i plugged the access point in, read some emails.. made me a cup of tea.. and i'd be damned if i touched the AP
i just noticed the Cisco logo is lit in orange (never before)
i logged in and the header now shows WAN IP: 192.168.2.111!!!
i had configured the AP as a repeater yesterday, with only the primary wlan interface running with the building's SSID and no virtual interfaces.
not sure what got it to work out of the blue.. i'm seriously puzzled
now i went on and configured a virtual interface with a secondary SSID, without encryption..
client nodes are connecting to it and all is working PERFECTLY
the last step was to add encryption.. so i set the wireless encryption to WPA2 PSK and set my key.
now the AP is no longer connecting to the remote network.
if i disable encryption on the virtual WLAN interface, everything works fine.
syslog shows nothing apart from
Jan 1 00:00:38 gw1 local0.debug udhcpc[168]: Sending discover...
on and on..
so it seems in the repeater mode, it's not possible to have encryption enabled on both the physical and virtual interfaces.. perhaps a bug?
hey wo-fo... good test idea. I enabled "Use NVRAM for client lease DB". No change in behavior with that setting.
louie: you asked if its possible to have encryption enabled on both the physical and virtual interfaces. I have tested security/encryption running on both interfaces simultaneously... running WEP. It has worked for me - I am running it that way now. Maybe its different with WPA-PSK. Make sure your SSID matches your secure connection on basic settings tab and the dynamic (autoap) functionality usually needs to be disabled when running security on the physical interface (since you're hard configuring your connection).
Marc,
The Physical interface with the repeated SSID is running WEP encryption, with the same keys as that of the main network i'm trying to repeat.. and that's fine as my AP is able to connect to the remote AP.
now for the virtual interface with the other SSID, i've tried enabling encryption with WEP, WPA, WPA2, etc.... basically the AP no longer connects to the remote network then.
i don't have any scripts running.
i could send you the nvram backup, but i noticed that doesn't store all the settings on v24 beta (everytime i restore it, i end up having to reconfigure wireless security by hand)
In the current version of dd-wrt v24beta, testers report that repeater mode sometimes drops the client.
Created a workaround script ("dhcp_kick.sh") that improves reliability by pinging the gateway and sending a signal to udhcpc (on the router) to force renew.
In 12 hours of testing the script decreases dropped packets from >10% to <1%, and almost completely eliminates client disconnects.
I personally prefer to use the autoap script, so I put this dhcp-kick in a version of the autoap.sh script (to simplify deployment) - which is also linked on the wiki page. The merged version is named "autoap_kick.sh". Hopefully this dhcp_kick should not be necessary with future releases of dd-wrt, and thus should not need to be merged with mainline autoap. Consider my code a hack/branch for now, for v24beta repeater mode.
Note: There is a pre-existing script "always_on.sh" which kills and restarts udhcpc (in contrast dhcp_kick just sends a signal to udhcpc). If dhcp_kick isn't helping then recommend testing the bigger hammer "always_on.sh":
http://www.dd-wrt.com/wiki/index.php/Useful_Scripts
Marc,
would the disconnection have something to do with the lease validity?
my AP was lease an IP for 48 hours, by the main AP in the building
and i've been connected to it now for the past 3 hours without any disconnections or interminent connection issues
i've had a remote SSH session established throughout the time tailing a log on a remote machine, and then incidently, watched a 58 minute streaming video without any problems..
i could safely say i haven't had any disconnections or DHCP problems (ipconfig /renew always got a lease also)
the only problem i have, is not being able to enable encryption on my own SSID running on the virtual interface :S
Marc & Louie... First off, glad you are making progress louie... Persistence is a virtue, along with patience and tenacity... You have all of those...
Louie... do you still have the ssid for the uplink side of the repeater set to "", which is blank? If so, when you go back to your own office and retry it and it takes a dump, it is probably because the unit grabbed a different ssid now and that ssid does not have your WPA and so forth running in it.. So that connection is a dead end... Do you verify the mac address of the target AP in the sysinfo page when it ever connects to anything?
Fix the uplink ssid of the repeater to the target AP's ssid and permanantly set that value... Then, if you have to, go back to the main building with it and get it to connect again.. That will make those values get stuck in its nvram, and when you go back to your own office again it will try to keep those values at bootup and it will take some definite commands that say otherwise coming from somewhere to get it to change again... Just a thought.. I know you probably already know this, but I am throwing it in the mix just in case....
MJ...... My hunch is with the DHCP instability issue, that the problem is with DNS when the unit traverses across networks... The IP is fine, but when the DNS changes it throws the pc out of whack because it still has the original DNS from when it first got its assignment from the router.. I don't think it is specific to windows, it will happen on any Operating System...
I think it would also help to just set a static DNS so it stays put... I am playing with this and I will report back, but I wanted to put that bug in your ear to think over...
With DNS Masq running, the DNS stays the same on the pc and the system does not seem to get confused, SO FAR...
My questions for MJ are these... Do you know how I can take this one step further and make it so,
1) The web download uses https so the file cannot be sniffed with ethereal? do I just make the download directory in my web server be an https directory, thereby making it issue an ssl key? Is that all there is to it? I will try it right now and probably have a preliminary answer shortly, but I would like your thoughts on this..
2) I want to make the web download directory for the script be password protected also, so google can't find it and post the script and other files up on the web for all to grab.. Do you know how to modify the Startup Commands you wrote to use a username and password when running the wget command?
These two things would really make this the shiz-nit... MJ... I have to go back and really congratulate you for this clever vision..
THIS IS A SUPER SMART APPROACH MARC!!!!!!!!!!!
Let's all give a big round of applause to MJ here.... Now I need to get MarcJ, JohnnyPrimus, and Bird333 together and putting their heads together on this even further... If we could now combine this methodology with what the two of them are currently working on also, I am telling you right now, WE WILL REALLY BE COOKING WITH PROPANE GAS GENTLEMEN!!!
Take care and I will check back, as I have been working on this solid for days now and I plan on sticking with it until it is perfected.... I have got my teeth in this thing and I am not letting go until it is all buttoned up from every angle...
THEN WE'LL SEE WHAT YOU SMART PEOPLE COME UP WITH NEXT!!!! I CAN'T WAIT!!!
Then I'll do what I do, which is organize it into a replicatable and usable form for the non-educated folks, thereby increasing the value of it by making it ACCESSIBLE TO ALL!!!!
This is what the whole open source community is all about... You guys are all that AND a box of cookies.....
bye for now,
wo-fo
Last edited by wo-fo on Mon Dec 04, 2006 2:45; edited 1 time in total
hi wo-fo: that's a great idea for a test... I have tested statically configured IP (no change), but not DNS.
About wget and https: I did a little testing, and it appears that wget (on dd-wrt) did not get compiled with ssl... so we cannot download the script over https. Long term, a request could be made to compile ssl into wget (memory permitting).
Nonetheless, there are some steps you can take now to hide and protect scripts, that will work with the current build:
1) Put the script in an unlinked directory on your server (that no other pages link to), and then the spiders cannot find it.
2) To confuse ethereal snoops, obfuscate the shell script using obfsh as described here:
http://comp.eonworks.com/scripts/obfuscate_shell_script-20011012.html
Back already.... I can tell that I am going to need to be told what to do with this obfuscation tool... Can you give me a brief how-to on this MJ ?
Another thing I am finding... Something in here kills the splashd daemon and I can't figure out how to restart it or make damn sure it is running after the script runs...
I can telnet in and run
splashd
or
/tmp/start_splashd.sh
and it will start manually and works fine... but I can't get it to start automatically... I think this might be a bug with V24, I am not sure... I will roll the config back to stock for a test and see...
wo-fo: i have in fact set the SSID manually since day 1.. i never left it blank
but i think i found my problem
when i run site survey, i'm finding the building's SSID twice with different MAC addresses, one has a low signal on SMC hardware, and one has an excellent signal on d-link hardware.
furthermore,
when i search and connect to the building SSID with my laptop, i always get Excellent signal (meaning i'm connecting to the D-Link AP)
however, with my AP, i always get a 10-16% signal (so it's connecting to the SMC AP, which happens to be one floor below)
i'm guessing these are setup as a bridge, cuz when i connect directly with my laptop, and the signal is excellent.. the gateway is 192.168.2.1, and that has an SMC web interface
is there a way to tell the MAC address of the wireless AP i'm connected to in windows?
i guess my problem is caused by my AP trying to join the network as a client first to the AP with strong signal.. when that fails (and it takes a little time) it tries the other one
so i either have to figure out how to make it work with the strong signal AP (d-link) or always connect to the other one by setting the SSID and MAC or so
Posted: Mon Dec 04, 2006 13:18 Post subject: Re: Universal Wireless Repeater
marcjohnson wrote:
I created wiki instructions for creating a Universal Wireless Repeater (or range expander, or wireless client bridge). I think a lot of people do this with two devices - whereas these instructions do it with one device. The instructions provide inclusion of a script to dynamically grab the strongest signal and repeat it. Could be another killer-app for dd-wrt:
If anyone wants to try to repeat the recipe, and help optimize it, please reply to this thread with your mileage.
The only problem I have currently is that my client (running XP) gets confused sometimes, and although the repeater is working fine and repeating, I have to renew my connection on the client side (using XP "repair" connection). I think this might have something to do with bridged mode, and perhaps because there are currently two DHCP servers running on the latest release of 2.4 (udhcpc & dnsmasq) which may confuse the client, but this is conjecture.
So for those who want to help optimize:
1) eliminate the step to repair the connection occasionally on XP (upon connection and at intermittent times)
2) maybe eliminate the bridged mode (so port forwarding is not required sometimes)
The wiki was created, and this article was posted, using the UWR
God bless you my friend! :* _________________ 1. Asus WL-500W, DD-WRT v24-sp1 ( 07/27/08 ) mega
2. Linksys WRT54GL v1.0, DD-WRT v24-sp1 ( 07/27/08 ) std
3. Linksys WRT54G v5, DD-WRT v23 SP2 ( 09/15/06 ) micro
can anyone give me a short summary whether or not the repeater mode is stable yet?
i get the impression that you are in the middle of testing and tweaking... i suppose you will only update the wiki once you are done or is that wiki up to date already?
:*