Jump to content

Search the Community

Showing results for tags 'wds bridge'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • General Discussion
    • Business Talk
    • What's Up
  • Neutron
    • Neutron Wireless
    • Neutron Switch/ Controller
    • AP Camera
    • ezMaster Software
    • New Ideas
  • Electron
    • Electron & Neutron Differences
    • Electron Outdoor Wireless
    • Electron Indoor Wireless
    • Electron Switch
    • New Ideas
  • Antennas
    • Antennas
    • New Ideas
  • Long Range Phone System
    • DuraFon series
    • FreeStyle Series
    • New Ideas
  • Router/ Gateway
    • Cloud Router
    • New Ideas
  • Surveillance
    • IP Camera
    • Video Management System
    • New Ideas
  • Mobile APPs
    • Router APPs
    • Camera APP
    • New Ideas
  • Other Products
    • Power Accessories
    • USB Adapter & Repeater
  • Knowledge Base Collection ( F.A.Q Format )
    • Getting Started
    • Configurations
    • Monitoring & Management
    • ezMaster

Blogs

There are no results to display.

There are no results to display.


Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Found 5 results

  1. I am getting about 5 per second of the following message in the logs on both radios in a wds bridge. What is the condition and what should be done? Feb 1 17:11:39 EnStationAC user.warn kernel: FWLOG: [105974500] WAL_DBGID_STA_VDEV_XRETRY ( 0x40 ) I do not share the channel with any detected APs although there are other 5 GHz units near.
  2. I am using 2 ENH500's. One (#1) is communicating with an ENH700EXT and an ENH900EXT, everything in WDS Bridge mode (5G Backhaul) and working. 2G is for customer devices and is also working. The other ENH500 (#2) is also communicating with another ENH700EXT, and as above, everything is functioning as it should. The issue arises when trying to add a new ENH1750EXT to the system (#2), it will not maintain a 5G Backhaul connection. It does not seem to matter which ENH500 I connect to, same problem, I have also swapped the ENH700EXT's (and the ENH900EXT) around, they don't have a problem but the ENH1750EXT does. I have compared the settings in the EHN500's, ENH900, ENH700's, and have applied those same settings to the new ENH1750EXT, I have installed the latest firmware twice, and a reset, twice, no luck. The ENH500 and the ENH1750 will both show a link status of 'UP', as soon as a customer tries to connect (2G) the link status on the ENH500 disappears, no UP, no 'DOWN, nothing, the line disappears completely. Link status on ENH1750 shows status as UP. Considering all of my existing devices are working, and the 1750 doesn't want to, what is wrong with it?
  3. Hi, We have a LAN with two EnstationAC radios connecting an outlying building to the LAN, the radios are in the operational mode WDS Bridge. The wireless connection is up and stable but connectivity to devices at the far end of the link is intermittent. For example, on the LAN side switch that is directly connected to the AC radio pinging the IP of a device at the far end fails with time out message, but if i log into the AC radio and ping the devices IP it responds and afterwards the switch is also able to ping the printer but then after a period of time the same happens all over again. On checking the arp table of the switch it does not contain the mac of the printer until the device is pinged from the AC radio, the mac of course then drops out of the mac address table on the switch after a period of inactivity. It looks like the EnstationAC is somehow blocking the switch from learning the macs of devices at the far end of the link. the switch is not having any issues learning macs of any devices on the rest of the network, we have already swapped out the switch as part of the troubleshooting process but made no difference. Are there any settings that i need to be aware of on these devices that would block the normal mac learning process. Any help/advice is appreciated, this is causing major connectivity issues for client devices.
  4. Slayman

    EnGenius Modes

    EnGenius' products offer several modes. Access Point, Client Bridge and WDS Bridge modes are the most popular.
  5. I have installed a pair of ENH500s between buildings with a clear line of site between the units but 4 power lines cutting the path above and below the line of site. The distance is about 85 yards between the units. The first unit (call it bridge1) is mounted on a pole ~30 ft above ground and between 10-15 feet above the roof peak. The second unit (bridge2) is mounted on the side of a house facing the first unit. It is ~15 ft above the bridge1 in elevation. The units appear identical, but bridge1 had the older metal POE injector with a wall-wart, while bridge2 came with the newer plastic one with built-in transformer. Bridge1 had an earlier firmware version (1.5.38?) which which I updated to 1.5.74 after verifying compatibility with Engenius Tech Support. Bridge2 came with 1.5.74 already installed. Both units are configured in WDS Bridge mode (as per Engeius' "ENH500 as WDS Bridge" document) with each other's MAC addresses entered in the correct location. The channel is set to 157 with 40MHz bandwidth. I checked with WiFi ananlyzer on my Android phone to verify that these channels were clear. I am seeing a strange asymmetry in transfer speeds between the bridges. Bridge1 is showing an RSSI of -41 (on WDS Link Status page) and the transfer speed from the speed test (on diagnostics page) is 31.7 Mbits/sec. Bridge2 is showing an RSSI of -43 and a transfer speed of 5.00 Mbits/sec. As this result seemed inexplicable, I tried with a pair of laptops connected to the links using iperf3. Iperf3 measured the transfer rate from Bridge1 to Bridge2 as 78.1 Mbits/sec, and the transfer rate from Bridge2 to Bridge1 as 5.35 Mbits/sec. This was approximately repeatable through multiple trials, and therefore, I believe that it reflects the true results. I also tried switching channels to 36 and got approximately the same results. I believe that the bridges are pointing at each other at least closely (both horizontally and vertically) and the RSSI would seem to bear that out. I have no explanation at this point as to what is going on and would greatly appreciate any suggestions as to how to diagnose and correct the issue. Thanks for any assistance you can offer. Mark Rondinaro
×

Important Information

By using this site, you agree to our Terms of Use.