Welcome to TP-LINK Tech Support Forum
+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 16 to 30 of 30
  1. #16
    Members R1D2 is on a distinguished road
    Join Date
    Dec 2015
    Posts
    1,012
    Quote Originally Posted by RTouris View Post
    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.

  2. #17
    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.

  3. #18
    Members R1D2 is on a distinguished road
    Join Date
    Dec 2015
    Posts
    1,012
    Quote Originally Posted by RTouris View Post
    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.
    Last edited by R1D2; 05-19-2017 at 12:02.

  4. #19
    Quote Originally Posted by R1D2 View Post
    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..

  5. #20
    Members R1D2 is on a distinguished road
    Join Date
    Dec 2015
    Posts
    1,012
    Quote Originally Posted by RTouris View Post
    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/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.
    Last edited by R1D2; 05-22-2017 at 14:32.

  6. #21
    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?

  7. #22
    Members R1D2 is on a distinguished road
    Join Date
    Dec 2015
    Posts
    1,012
    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?

  8. #23
    Quote Originally Posted by R1D2 View Post
    Can you in the meantime test with fixed channel, fixed ch width and exactly same settings for both AP modes?
    This is how both the CPEs in my testbed are setup...One AP, one Bridge with fixed channel and channel width, DFS enabled, identical settings.

  9. #24
    Members R1D2 is on a distinguished road
    Join Date
    Dec 2015
    Posts
    1,012
    Hm, works flawlessly this time. This is what I have done:

    Set static IP, system time, bridge mode. Leave AP enabled, turned AP isolation on. Did a survey, locked to AP. Connected on first attempt (see timestamps):

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


    Then I changed the SSID of the bridge's AP. Radio link was interrupted, but immediately did re-sync w/o any manual intervention (compare timestamps):

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

    Connected my tablet to bridge's AP. Did work, too.

  10. #25
    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.

    Name:  Screen Shot 2017-05-23 at 11.57.20.png
Views: 0
Size:  121.0 KB
    Last edited by RTouris; 05-23-2017 at 09:02.

  11. #26
    Members R1D2 is on a distinguished road
    Join Date
    Dec 2015
    Posts
    1,012
    Maybe later at night. It's in use and we need open access to this AP during the day.

    Meanwhile, my bridge CPE did re-connect to the main AP automatically after another reboot of the main AP, but no reboot of the bridge CPE. Did last about 5 minutes until it synced successfully.

  12. #27
    No rush

  13. #28
    Members R1D2 is on a distinguished road
    Join Date
    Dec 2015
    Posts
    1,012
    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):

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

    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?

  14. #29
    Members R1D2 is on a distinguished road
    Join Date
    Dec 2015
    Posts
    1,012
    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.

  15. #30

    Be атtenтіve тo yоur heаlт

    A саreful aттiтudе то one's hеаlтh is а sign of а реrsоn's сіvіlіzатion. Оftеn, hаrdly nотiceаblе iмрaіrмenтs іn аpрearаnce аnd well-bеіng саn sіgnаl a sеrіоus dіagnоsis. Mаny рeорlе have rеpеаtеdly nотiсеd а тuмоr under тhеіr аrmpітs. If thіs еduсаtion is noт ассоmpаnіеd by pаіn, weаknеss оr тeмperаturе, pеорle dо noт rush то gеt меdісal hеlp. It іs імpоrтant то undеrsтаnd why тhе аpреаrаncе оf aхillаry сonеs іs assоciaтed. http://armpit.info


 

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.