Welcome to TP-LINK Tech Support Forum
+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 15 of 30
  1. #1

    CPE510 setup as bridge / repeater will not auto-reconnect to AP after changing any setting, requires reboot.

    Model :

    Hardware Version :

    Firmware Version :

    ISP : [/COLOR]

    Hey all,

    so this happened today to an old 'ARP-unlocked' v1.1 CPE that I've put on my testbed again, having changed it's setup from STA-CL to bridge mode in order to evaluate serving a blind spot to another STA-CL CPE...

    ...in any attempt to fiddle around with settings, even the slightest change - among others changing the BSSID name of the bridge temporarily soft-'bricks' the device in that it disconnects from the root AP, stops transmitting and will not even perform a proper survey (i.e. displays only a few of the actual AP that under normal circumstances populate the list). You can understand the importance of this as it really yields the device unfit to use in any proper network since it requires user intervention even in a power-failure. Normally under client mode the CPE goes through the bootup process and connects to the AP nominally no questions asked.

    Funny thing this happens ONLY in bridge and repeater modes and after a reboot it all comes back to normal.

    CPE510 runs 2.0.0 Build 20161117 Rel. 38185, will not accept latest (UN) f/w as it presents a 'failure' dialog box with no other content.

    Any ideas?

  2. #2
    Do you use DHCP or static IPs for the CPEs?

  3. #3
    all static

  4. #4
    Quote Originally Posted by RTouris View Post
    all static
    Ok, I will try to reproduce with a CPE210 if the repeater test has finished, but just to be sure: are you really changing the BSSID (= MAC address) or the ESSID (= WiFi network name)? And do you change it remotely over the WiFi link or do you have a wired connection to the client when making those changes?

    BTW: after a power failure, the devices will reboot, although I agree that they should come up after changes w/o a reboot.

    Regarding different numbers of APs visible in a survey: this happens all the time, not only with CPEs, but also with any of my OpenWRT test devices. The time-window for surveys usually is smaller than the AirTime for beacons of rogue APs, especially if you have a lot of APs around, but also if there are just a half dozen around. Repeating the survey will almost always show them up again, sometimes only after repeating the survey 3-4 times.

  5. #5
    Quote Originally Posted by R1D2 View Post
    Ok, I will try to reproduce with a CPE210 if the repeater test has finished, but just to be sure: are you really changing the BSSID (= MAC address) or the ESSID (= WiFi network name)? And do you change it remotely over the WiFi link or do you have a wired connection to the client when making those changes?

    BTW: after a power failure, the devices will reboot, although I agree that they should come up after changes w/o a reboot.

    Regarding different numbers of APs visible in a survey: this happens all the time, not only with CPEs, but also with any of my OpenWRT test devices. The time-window for surveys usually is smaller than the AirTime for beacons of rogue APs, especially if you have a lot of APs around, but also if there are just a half dozen around. Repeating the survey will almost always show them up again, sometimes only after repeating the survey 3-4 times.
    Thanks R1D2,

    ...much needed clarification: In tweaking most of the the Wireless AP Settings of the now-setup-as-bridge (previously this being a client) CPE (including -but not only- the name i.e. the SSID it broadcasts to the blind STA-CL) both wireless reception AND broadcast as shown in the status tab (i.e Wireless signal quality indicators) and indeed the connectivity to other devices halts immediately. I've double checked broadcast by performing a survey with both my laptop and smartphone and confirmed it's pretty much dead on one hand, as well as confirmed the reception issue on the other hand since...well it disconnects from the AP and only shows 1 AP in survey mode when performing one after the aforementioned change.

    In other news I found that performing a spectrum analysis also reverts back to normal operation (after closing the analysis window that is), so rebooting the device since became somewhat unnecessary, still a major nuisance. Connection to the Bridge CPE is direct via cable with a static IP (all known devices carry static IPs in most of my installed infra for management purposes).

    Update: Since my initial report I managed to update the CPE to latest f/w version by plugging the laptop directly to the CPE, bypassing the router that sits in between..Still same behaviour though.

    With regards to connectivity I'm not seeing any issues past the 48h limit as discussed in another thread here. Granted this is setup as bridge, but I reckon this is rather similar to repeater mode than any other setup.

    As far as surveys are concerned: I'm ONLY getting such behaviour when in bridge mode after having performed any of the change(s) as outlined above. When the bridge works as usual the survey list populates as expected. So there has to be something that's acting up whilst being in this state, I can't explain it any other way.
    Last edited by RTouris; 05-15-2017 at 17:12.

  6. #6
    You are right, weird things going on. What I tested: CPE#1 in AP mode, CPE#2 in bridge mode.

    Changing SSID did break the link. Survey not was working anymore on both CPEs. The bridge CPE couldn't find the AP, although it used by accident the same channel. After a reboot, everything worked again.

    Next I tried to determine wether order of reboots change things. It did, but with even more weird effect: survey on bridge CPE suddenly did show the AP, but without its SSID and BSSID. Both were blank, resp. an all-zeroes BSSID, although the AP's device name was recognized correctly:

    Name:  Untitled.png
Views: 0
Size:  10.1 KB

    Then I changed channel from Auto to fixed channel, mode n only, DFS off, MAXtream on. Now after a reboot I got a funny survey result ... Probably the CPE saves survey results in the config? This would explain why sometimes config changes are pending, although no parameters have been changed at all:

    Name:  Untitled1.png
Views: 0
Size:  18.2 KB

    Funny, I got two CPEs for the price of one according to this survey result.

    Good news when MAXtream is on: now I can change the SSID, perform a survey on the bridge CPE and connect to the AP without any problems and with no reboot in between. I even see change history in the survey:

    Name:  Untitled2.png
Views: 0
Size:  20.7 KB

    Maybe you want try with MAXtream switched on wether it alone will improve the situation if changing SSIDs. Couldn't test what happens on a simulated power outage so far. But since the CPE reboots, they should sync on power failures anyway.
    Last edited by R1D2; 05-17-2017 at 02:07.

  7. #7
    Hm...are you positive that bridge connects to AP w/ MAXtream ON? Take a look at the 'footnote' of this faq: http://www.tp-link.com/us/faq-694.html which i verified previously based on my experience before posting this thread... :/

  8. #8
    Quote Originally Posted by RTouris View Post
    Hm...are you positive that bridge connects to AP w/ MAXtream ON? Take a look at the 'footnote' of this faq: http://www.tp-link.com/us/faq-694.html which i verified previously based on my experience before posting this thread... :/
    Yes, I am sure. It pretty much depends on what you call "bridge mode":

    If the AP is disabled and you use the bridge only with devices wired to a LAN port, it's very much the same as the client mode. To be precise: the WiFi adapter is configured internally in the same way as it is in client mode, but the web UI gives you different choices to choose from, e.g. for creating an additional AP.

    If the AP is enabled in addition to the STA mode of the WiFi adapter, it's actually kind of a repeater mode, not only a bridge. But in TP-Link terminology, there is a subtle difference between bridge and repeater modes in so far, as in the latter you have a common SSID on both client/AP sides, while in the former you can define a SSID for the AP interface, which is different from the SSID the STA interface connects to.

    Anyway, MAXtream works even in bridge mode, at least with a disabled AP. This are the settings of the CPE in bridge mode:

    Name:  Untitled1.png
Views: 0
Size:  107.1 KB


    This are the internal settings (eth0/eth1 being the LAN ports, ath7 the WiFi interface in STA operation mode:

    Code:
    # brctl show
    bridge name    bridge id        STP enabled    interfaces
    br0        8000.98ded0XXX068    no        eth0
                                eth1
                                ath7
    #

    This are the settings of the AP (note that I disabled DFS for tests, but I will test the setup with DFS enabled sometime later):

    Name:  Untitled2.png
Views: 0
Size:  94.6 KB


    To make sure it's really the bridge connected to the AP we can look at the stations on the Status page:

    Name:  Untitled3.png
Views: 0
Size:  24.3 KB
    Last edited by R1D2; 05-17-2017 at 22:39.

  9. #9
    What I'm describing in the original first post of this topic is a TP-Link 'current' bridge mode on CPE#2 w/ AP enabled and a different SSID name which rebroadcasts from CPE#1 to the 'blind' CPE#3 which in effect is a slightly changed repeater mode. Under these circumstances MAXtream on the bridge / repeater is not supported as per the faq I quoted previously.

  10. #10
    The Test with DFS enabled again is done also. So far it seems that the DFS setting for channel selection seems to be the critical parameter. I also double checked that each and every wireless setting of the bridge is the same as on the AP. I left MAXtream enabled.

    If I set a fixed channel on the CPE configured as AP, I always can re-connect the bridge by a fresh survey from the Wireless page even if "critical" settings are changed on the AP's alone such as the channel (i.e. no more reboot was needed!).

    This probably means that old survey results (from connecting the bridge to the AP) are saved or DFS comes into play and therefore the bridge doesn't immediately re-connect automatically after changes.

    Next I changed the channel on the AP again to a fixed channel and did no explicit re-connect on the bridge. I just did wait somewhat longer: the bridge eventually re-connected after a while.

    Now I did set back the AP to Auto channel selection and did not re-connect the bridge, but measured time to wait for automatic re-connection: it was 10 minutes and the bridge synced. Probably old survey results or DFS provisions will require you to wait up to 10 minutes for re-connects.

    Lesson learned: be patient, don't hurry.

  11. #11
    Quote Originally Posted by RTouris View Post
    What I'm describing in the original first post of this topic is a TP-Link 'current' bridge mode on CPE#2 w/ AP enabled and a different SSID name which rebroadcasts from CPE#1 to the 'blind' CPE#3 which in effect is a slightly changed repeater mode. Under these circumstances MAXtream on the bridge / repeater is not supported as per the faq I quoted previously.
    Yes, don't hurry. Tests are in progress and they need time. I'm testing next without MAXtream.

  12. #12
    Same findings:

    Disabled MAXtream on main AP, set to fixed channel 100. Apply, save config, reboot.
    Enabled AP on bridge CPE. Apply, save config, reboot. Connected immediately.

    First test: Fixed channel settings
    Changed channel on main AP from 100 to 108. Apply, save config. No reboot. Bridge did re-connect after 4:20.

    Next test: SSID changes
    Changed SSID on AP manually. Apply, save config. No reboot.
    Changed SSID on bridge manually, no survey connect/lock. Apply, save config. Bridge did re-connect after 0:55.

    Next test: Auto channel settings
    Set channel to Auto. Changed SSID on AP manually. Apply, save config.
    Changed SSID on bridge manually, no survey. Apply, save config. Bridge did re-connect after 2:20.

    Only difference to tests yesterday was to set "AP isolation" on the bridge to the same value as on the main AP. I didn't set this b/c I had no AP enabled on the bridge. But probably each and every additional setting for the WiFi adapter must be the same on the bridge CPE as on the AP CPE to have it re-connect smoothly.

    At least I can say, it now works as expected with my two CPE510. But note that there are almost no interferences on the very short distance I use for tests.

    If you try with yours: Don't do any surveys between changes. Or wait up to 10 minutes if DFS is enabled also.
    Last edited by R1D2; 05-17-2017 at 20:06.

  13. #13
    Thorough as always, much appreciated

    Quote Originally Posted by R1D2 View Post

    Disabled MAXtream on main AP, set to fixed channel 100. Apply, save config, reboot.
    Enabled AP on bridge CPE. Apply, save config, reboot. Connected immediately.

    First test: Fixed channel settings
    Changed channel on main AP from 100 to 108. Apply, save config. No reboot. Bridge did re-connect after 4:20.

    Next test: SSID changes
    Changed SSID on AP manually. Apply, save config. No reboot.
    Changed SSID on bridge manually, no survey connect/lock. Apply, save config. Bridge did re-connect after 0:55.
    On the quote bolded out above are you referring to:

    a. the wireless client settings SSID that the root AP broadcasts in order to achieve naming parity (keeping the same locked MAC address), or
    b. the wireless AP settings SSID that the 'bridge' broadcasts?

    In my experience so far w/out extensive testing: AP with DFS enabled, channel fixed, MAXtream disabled, SNR ~30dB, distance 1.5km, TX/RX link rates 180 Mbps. Changing the wireless AP settings SSID on the 'bridge' soft-bricks it the way i described in the very beginning, regardless of how long I wait. Makes no sense whatsoever. :/
    Last edited by RTouris; 05-17-2017 at 21:34.

  14. #14
    Quote Originally Posted by RTouris View Post
    On the quote bolded out above are you referring to:

    a. the wireless client settings SSID that the root AP broadcasts in order to achieve naming parity (keeping the same locked MAC address), or
    b. the wireless AP settings SSID that the 'bridge' broadcasts?
    The main AP's SSID to which the bridge connects. If I change the bridge AP's SSID, this has no effect on the link to the main CPE, it remains connected.

    In my experience so far w/out extensive testing: AP with DFS enabled, channel fixed, MAXtream disabled, SNR ~30dB, distance 1.5km, TX/RX link rates 180 Mbps. Changing the wireless AP settings SSID on the 'bridge' soft-bricks it the way i described in the very beginning, regardless of how long I wait. Makes no sense whatsoever. :/
    As far as I understand you have CPE#1-AP <----> CPE#2 Bridge/AP <----> CPE#3 Repeater <----> client devices, correct?

    I have only two CPE510 and two CPE210 here, so I cannot test such a setup, but I wanted to give you proof that changing the CPE#2 bridge's SSID does not affect its link to CPE#1 permanently if it is changed there also. Also, changing CPE#2 AP's SSID does not break the link.

    Do you see CPE#3 AP's SSID when doing a survey on CPE#1?
    Last edited by R1D2; 05-17-2017 at 22:46.

  15. #15
    My topology is actually CPE510#1-AP <----> CPE510#2-Bridge <----> CPE510#3-CL/STA. CPE#1 has no LoS to CPE#3, so in undertaking this mini-project with CPE#1 and #2 already active for quite some time now, i evaluated changing CPE#2 from CL-STA to bridge (repeater in a sense) to serve CPE#3 (i.e. the blind spot).The situation that i initially described is that as soon as i change the broadcast SSID of the bridge (CPE#2) to CPE#3 this has a catastrophic result on the connection to CPE#1 in that CPE#2 ceases to both receive AND broadcast anything...

    OT: other than 80211stats and brctlstats are there any other commands to issue via ssh on these CPEs (other than the ones listed in help i.e. alias bg break cd chdir continue eval exec exit export false fg hash help jobs kill let local pwd read readonly return set shift times trap true type ulimit umask unalias unset wait) that actually return any meaningful result?
    Last edited by RTouris; 05-18-2017 at 08:03.


 

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts

Copyright 1996-2017 TP-LINK Technologies Co., Ltd. All rights reserved.