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.

Thorough as always, much appreciated :)

R1D2 wrote

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. :/

RTouris wrote

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?

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?

RTouris wrote

CPE#1 has no LoS to CPE#3

O.k., then I am pretty sure that your setup hits the hidden node problem.

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.

RTouris wrote

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.

R1D2 wrote

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..

RTouris wrote

Could this be attributed to HNP and the collisions that you describe?

Definitely yes.

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/Carrier-sense_multiple_access_with_collision_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.

Right...

..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?