Your reports for Ralink/Mediatek units are highly appreciated !
Router:
Firmware:
Kernel:
Status:
Reset:
Errors: _________________ THERE ARE NO STRANGERS HERE; ONLY FRIENDS YOU HAVEN'T YET MET.
________________________________________________________________________________________________________
DD-WRT CHANGELOG | DEVICES | DD-WRT BUILDS | KONG BUILDS | UNOFFICIAL BUILDS | DD-WRT in VIRTUALBOX
Last edited by KrypteX on Wed Jul 08, 2015 9:49; edited 3 times in total
Router: ASUS RT-N10+ (B1)
Firmware: DD-WRT v3.0-r27490 (07/06/15) std
Kernel: Linux 3.2.69 #17743 Mon Jul 6 08:22:07 CEST 2015 mips
Status: OK
Reset: NO
Errors: Too many log entries
Jul 6 18:48:21 petinga kern.info ap_client: apcli0 is still associated
Jul 6 18:49:21 petinga kern.info ap_client: apcli0 is still associated
Jul 6 18:50:21 petinga kern.info ap_client: apcli0 is still associated
Jul 6 18:51:21 petinga kern.info ap_client: apcli0 is still associated
Jul 6 18:52:21 petinga kern.info ap_client: apcli0 is still associated
Jul 6 18:53:21 petinga kern.info ap_client: apcli0 is still associated
I don't see the need to create a log entry every minute, that's 43 200 log messages after 30 days.
Jul 6 18:48:21 petinga kern.info ap_client: apcli0 is still associated
Jul 6 18:49:21 petinga kern.info ap_client: apcli0 is still associated
Jul 6 18:50:21 petinga kern.info ap_client: apcli0 is still associated
Jul 6 18:51:21 petinga kern.info ap_client: apcli0 is still associated
Jul 6 18:52:21 petinga kern.info ap_client: apcli0 is still associated
Jul 6 18:53:21 petinga kern.info ap_client: apcli0 is still associated
I don't see the need to create a log entry every minute, that's 43 200 log messages after 30 days.
Router: D-Link DIR-615 D2
Firmware: 27490
Kernel: 3.2.69
Status: OK
Reset: 30/30/30 before and after update from 27147
Errors:
1) Repeater mode still can't auto connect to Remote AP http://svn.dd-wrt.com/ticket/3809#comment:35
Upgrade:
Upgrade from r27456 w/o 30/30/30, restored settings from status before = upgrade ok w/o any problems.
Auto Channel Selection:
AP Chan.13 lower HT40 Acrylic 13+9 |connected after
RepBri Auto lower HT40 Acrylic 13+9 |reboot of RepBri
AP Chan. 9 upper HT40 Acrylic 9+13 |no connection
RepBri Auto upper HT40 Acrylic 9+5 |at all
AP Chan. 9 lower HT40 Acrylic 9+5 |connected after
RepBri Auto lower HT40 Acrylic 9+5 |reboot of RepBri
Channel selection "Auto" works basically but not allways properly.
I only checked these two channels because lower channels are densely populated by the neighborhood.
It seems that "lower" works, "upper" doesn't.
I hope you're able to make use if these information.
ervau
@ervau
Thanks for the info, but you probably realized that the Repeater will connect if previously set channel matched the Remote AP. We have to do tests that specifically sets a different channel (even with Auto) beforehand, and see if the Repeater will switch to the correct channel.
I'll do some more tests now, but my preliminary tests show this is still not working as it should.
BTW, I have a script for Auto scanning of Remote AP, which was kindly provided by user Specimen, and which actually works. I think that I'll go back to 27456 and Specimen's script, which worked pretty well for me. I have no idea what would happen if I pair the Auto channel fixes in 27490 with Specimen's script... but I guess they would disturb each other and it would be a disaster. I will try, though. _________________ THERE ARE NO STRANGERS HERE; ONLY FRIENDS YOU HAVEN'T YET MET.
________________________________________________________________________________________________________
DD-WRT CHANGELOG | DEVICES | DD-WRT BUILDS | KONG BUILDS | UNOFFICIAL BUILDS | DD-WRT in VIRTUALBOX
Hallo,
just switched over from channel 13 to channel 5 on the Router. Repeater followed with a delay of some seconds. Than switched back to channel 13 on the Router; same effect. Repeater followed some seconds later. All the other setting untouched.
ervau
ps: it was a new test, nothing to do with what I described in my last post.
BTW, I have a script for Auto scanning of Remote AP, which was kindly provided by user Specimen, and which actually works. I think that I'll go back to 27456 and Specimen's script, which worked pretty well for me. I have no idea what would happen if I pair the Auto channel fixes in 27490 with Specimen's script... but I guess they would disturb each other and it would be a disaster. I will try, though.
No worries, AFAIK, you are safe to run the script in conjunction with Auto ch switching.
That's actually the setup I'm using, I'm still running my script on 27490, my script is fairly well behaved, think of it as automating you doing a site survey and the changing the channel number manually, the way it detects if it's still connected is by pinging the gateway/AP IP.
What the introduced Auto ch. does, I think, is just check if it's still associated with the AP and then if it isn't it does a site survey and picks the first channel matching the first network it finds with the matching SSID.
They work very differently and I think they can actually complement each other.
So I don't see any incompatibilities between the two, the Auto channel switching should detect the channel switch earlier than my script (in my case is set to run in cron every 3 minutes), but if that doesn't happen my script will change the channel, and then the Auto Ch will just detect it's on the same channel and accept that.
My script changes the channel at the nvram level and then restarts the service(s), this is exactly the same process as changing channels via WebGUI.
My script has one advantage over the Auto ch, and is the fact that is 'smart' enough to pick the channel that has stronger signal if there is more than one AP with the same SSID (this is useful for those captive portal APs in hotels, airports and such).
As for testing the Auto ch., I've been waiting passively for the AP to change channel (and then peek in the logs and see if it was auto ch. or my script that switched channel at the bridge, which is this Ralink router), since yesterday, but it's been pretty stable.
Hallo,
just switched over from channel 13 to channel 5 on the Router. Repeater followed with a delay of some seconds. Than switched back to channel 13 on the Router; same effect. Repeater followed some seconds later. All the other setting untouched.
Yes, the Repeater follows the channel change of the Remote AP, but disassociates from it after a few seconds. There's no internet access on the Repeater, it doesn't stay associated to the Remote AP. See the debug info (from the System Log) in my ticket report: http://svn.dd-wrt.com/ticket/3809#comment:38 _________________ THERE ARE NO STRANGERS HERE; ONLY FRIENDS YOU HAVEN'T YET MET.
________________________________________________________________________________________________________
DD-WRT CHANGELOG | DEVICES | DD-WRT BUILDS | KONG BUILDS | UNOFFICIAL BUILDS | DD-WRT in VIRTUALBOX
Switching back and forth I have a stable connection over the repeater - AP - to the INet and from the router to the repeater; i.e. I can reach the repeater from the router's side; pc is LAN-connected to the router.
Can you please teach me how to read out the logs?!
@ervau
You can verify the debug info like this:
1) Services -> Services -> System Log : Enable. Apply & Reboot.
2) Connect with scp (use WinSCP for that) to the Repeater (user: root, password: the one used to login to WebGUI). On the Repeater's file system, open the file /tmp/var/log/messages
You should be connected like this: PC -> Repeater -> Remote AP -> Internet
My particular connection is: PC -> Repeater (DIR-615d) -> Remote AP (WNDR3800) -> Internet
Note: Make sure to have a LAN cable connection between the PC and Repeater, to be sure that it's always connected to the Repeater and not to the Remote AP (which might happen if you connect your PC via WiFi).
On the other hand, the Repeater will be connected via WiFi to the Remote AP, obviously.
Check if you still have internet on the PC after you change the channel on the Remote AP. That's the best test you can do. After changing the channel on the Remote AP, verify the /tmp/var/log/messages file on the Repeater and you'll see periodic association/disassociation loops. At least that's what I have on my DIR-615 D2 Repeater with r27490: http://svn.dd-wrt.com/ticket/3809#comment:38 _________________ THERE ARE NO STRANGERS HERE; ONLY FRIENDS YOU HAVEN'T YET MET.
________________________________________________________________________________________________________
DD-WRT CHANGELOG | DEVICES | DD-WRT BUILDS | KONG BUILDS | UNOFFICIAL BUILDS | DD-WRT in VIRTUALBOX
1st I tried the easy way
Situation1:
PC (Win7) --(LAN)-> Remote AP --(WLAN)-> Repeater
Switched from 13 to 8 and back.
As already explained, I reach the repeater's setup site via Firefox w/o any problems, after a delay of 30sec (repeater show the right channel in sysinfo).
Situation2:
Notebook (Debian8) --(LAN)-> Repeater --(WLAN)-> Remote AP --(LAN)-> Modem -> INet
Switched from 5 to 13 to 8 to 13 from the notebook's side!!! i.e. over the repeater to the router. Waiting for about 30sec. (repeater show the right channel in sysinfo). I reached the router's configuration site and INet w/o problems via Firefox as well.
Pinged "Google.com" for several, channels for allmost 50 packets -> no significant problems (maybe not enough packets???).
See attached files. (file not files site doesn't accept Linux-files without extension)
2nd readout the log file; I will try but I have to figure out how to do.
Last edited by ervau on Wed Jul 08, 2015 15:41; edited 1 time in total
1st I tried the easy way
Situation1:
PC (Win7) --(LAN)-> Remote AP --(WLAN)-> Repeater
Switched from 13 to 8 and back.
As already explained, I reach the repeater's setup site via Firefox w/o any problems, after a delay of 30sec.
Situation2:
Notebook (Debian8) --(LAN)-> Repeater --(WLAN)-> Remote AP --(LAN)-> Modem -> INet
Switched from 5 to 13 to 8 to 13 from the notebook's side!!! i.e. over the repeater to the router. Waiting for about 30sec. I reached the router's configuration site and INet w/o problems via Firefox as well.
Pinged "Google.com" for several, channels for allmost 50 packets -> no significant problems (maybe not enough packets???).
See attached files. (file not files site doesn't accept Linux-files without extension)
2nd readout the log file; I will try but I have to figure out how to do.
