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

Welcome to TP-LINK Tech Support Forum

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Either change the roles (CPE#1 in client mode <---> CPE#2 in AP mode <---> CPE#3 in client mode), so you can use MAXtream or enable RTS/CTS on all three CPEs at least. You notice collisions on the links only in initial connection state or by achieving bad throughput once the radio links are in place.

I'm familiar with the Hidden Node Problem, but I'm willing to go fwd as CPE#3 has no real challenging setup / requirements and it occasionally needs internet access. So in effect I'm just testing out the CPE#2-Bridge to serve access to CPE#3-CL/STA. Longstanding issue being the one I'm describing with regards to how CPE#2 behaves in Bridge mode w/ AP enabled.

I'm familiar with the Hidden Node Problem, but I'm willing to go fwd as CPE#3 has no real challenging setup / requirements and it occasionally needs internet access.

I'm not sure I understand you correctly regarding setup challenge, but I meant the HNP is most certainly the cause for the disruption of the link between CPE#1 and CPE#2 if you change something at CPE#3 as described in your first post. Sending data from CPE#3 to CPE#2 can cause collisions if CPE#1 sends to CPE#2 at the same time. DFS then probably will block the channel for up to 10 minutes. If this happens on other channels too, you will wait endlessly for a re-connection.

You should at least use RTS on all CPEs in such situations, which can help somewhat, although it's not a 100% perfect solution.

As for interesting cmdline utils: depends on what your interested in, but apstats and ath0stats may be helpful for link diagnosis, also the family of iw* commands.

I meant the HNP is most certainly the cause for the disruption of the link between CPE#1 and CPE#2 if you change something at CPE#3 as described in your first post. Sending data from CPE#3 to CPE#2 can cause collisions if CPE#1 sends to CPE#2 at the same time. DFS then probably will block the channel for up to 10 minutes. If this happens on other channels too, you will wait endlessly for a re-connection.

In my first post I am describing changes made to CPE#2 - the bridge (situated in-between the AP and the STA/CL wrt to link topology) that have a disruptive effect on the links to both the CPE#1 i.e. the root-AP and CPE#3 i.e. the STA/CL, not any other way around. However this is not due to either CPE#1 and/or CPE#3 modes, as it appears as though it's actually CPE#2 that's having a difficult time both receiving and passing on the broadcast.

Could this be attributed to HNP and the collisions that you describe? Possibly so, however this brings up two fairly clear questions.

Firstly why would there be an option to use the bridge mode with AP set to ON, if such a result cannot be avoided when making such changes...
Secondly why if setup as a bridge with the AP set to ON and initially connected both links to the AP and the STA/CL work like a charm (notwithstanding the fact that in a case of link-loss it all goes pear-shaped afterwards...).

The HNP should have an impact on network topology (i.e. IP resolutions within the local network, possibly port forward and uPnP collisions, too), but I'm not at all convinced that it could / should somehow impact and hinder the reception and transmission mechanics of the devices involved..

Firstly why would there be an option to use the bridge mode with AP set to ON, if such a result cannot be avoided when making such changes...

PharOS lets you choose almost any setting possible, it's a business-class device for power users. Choosing meaningful options for a robust network topology is up to the user.

Secondly why if setup as a bridge with the AP set to ON and initially connected both links to the AP and the STA/CL work like a charm (notwithstanding the fact that in a case of link-loss it all goes pear-shaped afterwards...).

The difference between bridge-with-AP mode is the topology. Using CPE#1 as AP and CPE#2 as client is something completely different then using CPE#2 as a bridge! In former setup the HNP is non-existent. If you want to compare such setups, then bridge mode would be more similar to CPE#1 and CPE#3 in Client mode and CPE#2 in AP mode. But then, the HNP comes into play.

Bridge mode is - like the name suggests - a way to bridge two LANs together over a radio link. The possibility to switch on AP mode on the remote side of the bridge is just to save another AP at the remote side, but it will be subject to the HNP if the main (local) AP can't see the clients connecting to the bridge's AP. Same problem as with in repeater mode and also same problem as if you would use a completely different device for the remote AP using the same WiFi channel as the bridge does. In fact, bridge-with-AP and repeater modes are very bad choices for directional radio links over big distances.

The HNP should have an impact on network topology (i.e. IP resolutions within the local network, possibly port forward and uPnP collisions, too), but I'm not at all convinced that it could / should somehow impact and hinder the reception and transmission mechanics of the devices involved..

Of course it does so. All radio devices (and I mean literally all devices) always listen into the air to detect traffic to determine free slots before sending. They even listen to what they send out itself in order to be able to detect collisions.This is how CSMA/CA (similar to CSMA/CD in TCP/IP) works. The CA stands for Collision Avoidance and it's a common strategy to avoid such collisions, but it can't be 100% reliable by nature of this technique.
See https://en.wikipedia.org/wiki/Carrie...sion_avoidance for the gory details.

If any two devices send data at the same time on the same channel, there will be collisions. Thus, the HNP can occur at any time if more than two devices are sharing the same WiFi channel. And yes, they have an impact to the mechanics of the devices involved, since in bridge-with-AP mode you are forced to use the same channel for feeding the clients as for communicating with the main AP.

Don't use bridge mode, use AP mode for the middle CPE and client mode for the CPEs on the edges, so you can use MAXtream. This is what MAXtream was invented for at all.

..the thing is however that all this would make perfect sense with CPE#3 - STA/CL being indeed active, however after performing tests between CPE#1 - AP and CPE#2 - bridge (w/ AP enabled) with CPE#3 disabled completely I'm still facing the issues described as you pointed out in post #6 of this topic...

So in a sense I believe we're back at square one...Could you try again and report back?

Yes, but note that for the tests in #6 I had differing WiFi settings. I had AP isolation enabled on main AP and disabled on the bridge's AP. Then I disabled everything (even the bridge's AP at all) and did build it up from the beginning testing after each change. Since then, no weird MAC address such as 00:00:00:00:00:00 appeared. Only remarkable fact was that with DFS enabled and auto channel selection I had to wait long time for syncs if I did a survey in between changes. Can you in the meantime test with fixed channel, fixed ch width and exactly same settings for both AP modes?

Would you give it another go with AP isolation disabled? Just noticed that you have no WPA2/AES security set, could you also please enable and re-test? Other than AP isolation which is not enabled and WPA2-PSK/AES I also have an IP camera connected to port1 of my bridge which also works flawlessly.

Disabled AP Isolation and set WPA2 key with AES encryption on main AP at 23:11:22 and bridge at 23:13:15. Bridge did re-connect almost immediately after I applied/saved the config; exactly at 23:13:28 the link was up and running again (see connection time):

It now works much better than recently when I wrote post #6. No idea what makes this difference, probably environmental influences I'm not aware of?

I now reverted settings in the opposite order: first enabled AP isolation and set no encryption on bridge and then on AP. Interestingly, AP changed the channel from 112 to 124 and bridge did not re-connect immediately. It eventually synced after 14 minutes since AP has been changed. I think it's indeed DFS what causes such effects.