Do you use DHCP or static IPs for the CPEs?

all static

RTouris wrote

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.

R1D2 wrote

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.

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:





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:





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:





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.

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

RTouris wrote

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:






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
# [/CODE]


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):






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

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.

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

RTouris wrote

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.