I had the same exact bug with my StarOS WRAPs trying to talk to UBNT units in PTP mode. My temporary fix was to reverse their roles. In other words, make the UBNT unit the AP and the WRAP the station. Go figure! -RickG
On Tue, Jul 13, 2010 at 6:08 PM, Justin Mann <justinl...@unwiredwest.com> wrote: > Hello, > > My name is Justin. I work for Mark Nash, whom I'm sure you have heard > from before. I'm his company's engineer. This is my first time writing > into or reading the WISPA list; Mark suggested that some people here > might be able to help me with a particular issue we have been > experiencing. If anyone here has suggestions as to what the issue would > be, I would appreciate it. > > Here is my scenario. We have two sites; we will call them "A" and "B". > > At site "A" we have a Mikrotik router, running RouterOS v4.5. At site > "B" we have 3 StarOS access points. > > Each access point has a /30 on it's ethernet side, shared with the > router, and uses RIP. We have a bridged StarOS backhaul between them. It > works pleasantly; the router has never failed to pick up the remote > networks on the access points before. Recently, we have wanted to > replace our StarOS backhauls with UBNT Rocket backhauls. > > When we attempted to do this, we encountered a very strange bug with no > workaround I could find. When we switch to the Rocket backhaul, we can > no longer communicate with remote networks. Now, both the APs and the > Router are still running RIP - and you can look at the RIP routing > information and see that the router has indeed received the downstream > routes. However, we can only communicate with the /30s. If we attempted > to reach the remote networks, it returns as unreachable - and if we > attempt to trace those networks, it seems that the Mikrotik router is > attempting to route traffic to an internal-only address assigned to the > Rocket backhaul devices. > > Example. Network 1.0.0.0/24 is on the far side of Access point A. With > the StarOS bridged backhauls, the Mikrotik router successfully adds a > route to its kernel routing table to route 1.0.0.0/24 through the /30 > assigned to the access point. In our failure scenario with the Rockets, > the same route is successfully received via RIP, and you can see that > 1.0.0.0/24 is still pointing correctly to the /30. However, when the > router actually attempts to forward a packet, it forwards the packet to > an internal-only address assigned to the Rocket Backhauls, an address > that does not appear ANYWHERE in the router's routing table. > > What makes it more difficult is that even static routes do not work. If > RIP is disabled on the respective devices, and a static route is > entered, it still fails to work - it even fails to work if you > completely remove the internal network from the router, and leave only > the /30s on the interface, with a static route. The router still cannot > communicate with downstream networks - only the /30 directly connected > to it. this only happens with the UBNT rocket AP is in place. > > Currently, the rockets are configured as bridges, in AP and Station > mode, with AirMax enabled. > > If anyone has any advice I would appreciate it. > > > -------------------------------------------------------------------------------- > WISPA Wants You! Join today! > http://signup.wispa.org/ > -------------------------------------------------------------------------------- > > WISPA Wireless List: wireless@wispa.org > > Subscribe/Unsubscribe: > http://lists.wispa.org/mailman/listinfo/wireless > > Archives: http://lists.wispa.org/pipermail/wireless/ > -------------------------------------------------------------------------------- WISPA Wants You! Join today! http://signup.wispa.org/ -------------------------------------------------------------------------------- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
