Bekijk de volledige versie : Firmware v1.7.5.6 CR2.1 [Oleg]
Antiloop
28-04-2004, 21:44
Changelog:
+ Fixed usb printer driver
+ Added VI editor compiled in busybox
also see this thread for changelog for CR2 http://wl500g.info/showthread.php?t=249
find firmware here: http://files.wl500g.info/asus/wl500g/firmware/customized/1.7.5.6-2/wl500g-1.7.5.6-2.1.trx
antiloop,
when we use this firmware, can we use it together with the USB root fs for 1.7.5.6-CR2?
i'm quite confused what comes from the firmware and what from the external USB source....at first i thought that one replaces the other, but the fact that all my settings were remembered after switching to external USB disabused me...
it was about time for an editor.... keep up that great work :)
cheers, thomas.
Antiloop
29-04-2004, 14:32
when using rootfs(cr2) from usbkey, the wl500g boots up from your usbkey
so you need to overwrite your usbkey/hdd with the rootfs from this firmware.
maybe oleg can supply the rootfs of CR2.1
Guys, just to clarify: this firmware is in fact the test firmware posted for resolving problems with kernel oopsses. I'm still waiting for the feedback on that and once I'm be able to resolve this terrible issue I will post the 1.7.5.6-3 firmware, sources & rootfs. Please wait for this.
Guys, just to clarify: this firmware is in fact the test firmware posted for resolving problems with kernel oopsses. I'm still waiting for the feedback on that and once I'm be able to resolve this terrible issue I will post the 1.7.5.6-3 firmware, sources & rootfs. Please wait for this.
Oleg, could you please add the attached files to filesystem of your new customized firmware? ASP files should be placed to web folder, client script should be somewhere in the path (perhaps in the bin folder?).
With these files it should be possible to change the Admin name from the web configurator menu, client script should allow to enter the Client mode easily. Please note the files may be buggy so please correct it if you find any problem.
BTW I have encountered a strange thing - it seems the reset to defaults does NOT set all variables properly... I am running 1.7.5.6-test2 (1.7.5.6-2.1) but I believe the same problem will be with original ASUS firmware. Today I had to reset the WL-500g configuration to defaults (using RESTORE button). The 'wl txpwr' command returned 255 (despite several reboots) until I have applied a Wireless-Advanced config page. I did not test the 'hard' reboot (power off) but this behaviour is not OK anyway I think...
Ok. The script should go to the /init and I think the name should be rc.clientmode. The scripts looks like a hack for me. But it's better than nothing...
Antiloop
30-04-2004, 15:48
well.. better that than nothing, and the firmware is messed up it in the inside anyway already :D
Technik, I finally decide not to include cleint mode stuff like this. We need to make right firmware with no glitches. So, I've checked the init scripts in figure out how we could "natively" support client mode. So, can you please perform the following test: we need to figure out how to initialize STA mode (bss/ibss) using the "right" commands. So, in order to do this specify all wireless settings you need via the web interface, then reboot the router. In the shell prompt please enter the following commands:
wlcfg eth2 down
nvram set wl0_mode=sta
wlcfg eth2 up
and then check if wireless network functional (i.e. have associated). Also, if you need IBSS mode instead of BSS try
adding
nvram set wl0_infra=1
before eth2 up. Also you could switch it to WET (client mode bridge???) mode by specifying "wet" instead of "sta".
Also, you could probably need to set wl0_channel to 0.
Please let me know if it works for you.
wlcfg eth2 down
nvram set wl0_mode=sta
wlcfg eth2 up
You are right, Oleg. I can confirm that command sequence above is working and I am able to associate with the requested AP using 'wl join' command.
I've expected what wl join does not need at all. Can you check on this?
Also, does channel setting affect the client mode?
I've expected what wl join does not need at all. Can you check on this?
Also, does channel setting affect the client mode?
Well, you will always need to use the join command to specify which AP you wish to connect. Otherwise you stay disassociated even if there's only one AP visible. I did not test the channel setting change yet as I can't easily perform the test right now. But I think it's not very important - usually I don't care about channels at all. The nice option would be to have a possibility to join BSSID instead of SSID (which can be exactly the same for more APs in range). The BSSID should be always unique...
Well, you will always need to use the join command to specify which AP you wish to connect.
AP == SSID. And we've already specified it via wireless settings...
AP == SSID. And we've already specified it via wireless settings...
Hmmm... The strange thing is that I get 'associated' even if there's no signal. The BSSID is random (always different after wlcfg eth2 down and wlcfg eth2 up), RSSI and NOISE = 0. The channel is changed in accordance to nvram wl0_channel variable. When I try join and it's not successful, I get disassociated. In my opinion we will have to use join command in loop to be sure the association is correctly made. This part of my script was working perfectly.
Loop is not a good thing in the firmware, so we need to figure out the correct way. With regular linux wireless modules you don't need to loop or join anything with special commands. I think the same applies to broadcom modules.
Just a thought - have you tried to set channel to auto?
Loop is not a good thing in the firmware, so we need to figure out the correct way. With regular linux wireless modules you don't need to loop or join anything with special commands. I think the same applies to broadcom modules.
Just a thought - have you tried to set channel to auto?
Yes the channel auto was set as default first...
Oleg, I don't see any problem with the loop as it needs to be run just one time. If the signal quality is good, it's only few seconds delay. It would be nice if we could get broadcom modules working as expected but I had no luck with this so far. In my opinion the part of module code must be a fake because of random BSSID associated... It's strange. Did you test it as well? The question is how does it work on another device if there's no signal... I think the BSSID should go to all zeroes and change to correct numbers as soon as the matched SSID is found. This happens if I get associated by the join command and loose an AP signal afterwards. The BSSID changes to all zeroes. If the signal level is up again, the BSSID is changed back to correct one and the connectivity is restored automatically.
Personally I've not tested this, because I do not use client mode. That's why I'm asking you to do this.
As for existing association - this due to the fact wl module was previously in AP mode and shoing garbage to you. Don't worry - new firmware will switch it to the right state with no broken association.
As for loops - I think there will be one like this
while sleep 15s; do if ! $(wl assoc | grep -q BSSID); then wl join $(nvram get wl0_ssid); fi; done
This will catch reassociation (in case APs signal is lost) also. Try this one, but perform wl disassoc before it (hope this helps now).
Oleg, your script works fine but it's not necessary to keep it running all the time. You can exit as soon as the first successful join is made. Otherwise you should exit with error status after while (in case the signal is poor or none). That's why I put the LIMIT variable into my stupid script ;) - as per my experience - if you can't connect in about 30 seconds, it does not make sense to continue associating. There's no problem with loosing signal as I already tried to explain in my previous post. So you don't need to fix that situation by permanently running script. The join script should be initiated during the boot (only if the router is configured for Client mode of course) and occassionally by activating some Connect button in web configurator (so user could perform it anytime - perhaps another variable instead of router's SSID should be used).
BTW, AFAIK some concurrent APs with client mode support can connect using BSSID (MAC address in fact). Maybe I was blind but I did not find any possibility to use that parameter in WL-500g so far. As some access points does not use SSID at all, it's hard to associate them... :confused:
Hm, but suppose your wl500g see 2 APs and the current dies - do we need to reassociate with it? I think yes, that's why the script should run continously. Any thoughts?
As for BSSID - how to associate using it it?
Hm, but suppose your wl500g see 2 APs and the current dies - do we need to reassociate with it? I think yes, that's why the script should run continously. Any thoughts?
Well, usually there are only AP's with unique SSID's in range. I can't easily check it but I think in case there are two APs with the same SSID, you will be probably automatically reassociated to the AP with better signal level.
You can be sure the reassociation works automatically without any problem - really NO need to run join again - just one time (or better say until successful association) is enough. Works perfectly for me (joined AP manually 2 months ago) - I have unplugged the antenna many times for a long time. The RSSI and NOISE was frozen then and BSSID changed to all zeroes. After connecting antenna back to router, the these variables returned back to actual values and I could ping to remote AP again without any additional procedure.
As for BSSID - how to associate using it it?
That's what I would really like to know... :( In my opinion it's not possible on WL-500g with current wl module. But D-Link uses that way of association: http://support.dlink.com/techtool/DWL900AP+/Emulator/adv_mode.html
It allows to connect concrete AP even if there are APs with the same SSID (sometimes it's a disadvantage of course - it would be nice to have both options).